Re: [PHP-DEV] Large file support for PHP
On Tuesday 16 October 2007 04:37:57 pm Wez Furlong wrote: PHP's native integer type is long, how else are you going to relay numbers longer than a long back to the script without rewriting the engine to add additional integer types, which is a massive changeset? okay, chalk this up to my IANAPHPD ignorance. Or just bump our API number(s) and not worry about it, since the module loading code will refuse to load an incompatible module. PHP 5.3 is an ideal point to make this kind of change, as I've already stated. the general impression that i got was that zend/php did not want to break their abi because then they'd have to support an additional set of platforms for the zend optimiser. but maybe that was just hearsay. sean signature.asc Description: This is a digitally signed message part.
Re: [PHP-DEV] Large file support for PHP
but this wouldn't be any different from any other api/abi bump. furthermore, Of course. If there are two different PHP versions with different API numbers, it's OK. What's less OK is when there's two PHP builds with same API numbers which are binary incompatible. in the context of running debian (and by extension ubuntu) servers, you wouldn't need to do anything if you were only using the pre-packaged modules, You mean - pre-packaged by Debian? need to do an apt-get upgrade, etc. and if you were using other pecl extensions, i think the command to update that isn't so complicated either :) Compatibility is not complicated if you deal with one machine where you control everything and can rebuild everything from source. It starts to get worse when you have a lot of machines on which you want to achieve some kind of common environment. Having indistinguishable binary incompatible PHP versions complicates things. -- 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] php 5.2.4 test results reference
Hi folks working at Sun Microsystems QA org we are integrating php into our new Open Solaris release (php 5.2.4 for now) we have run the functional test suite shipped within the php release to address/assess non regression testing area similarly we have run the php 5.2.4 test suite vs a Red Hat 4 platform to generate a base of comparison for test results between Solaris and RH as we have caught some failed tests on Solaris (less on RH) (detailed test report is available on our side) we would like to know whether at php org level there are any test results available / published / shared per OS (like Solaris, RH in particular) in order we can compare the results obtained on Solaris with some official run and therefore get a status about failed tests we caught : typically are there known bugs per OS (corresponding to failed tests) already filed for php 5.2.4 release thks in advance Jean -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method overloading by method signature
On 17/10/2007, Stanislav Malyshev [EMAIL PROTECTED] wrote: suit fully fitted) catch-up. (Hey when has documentation EVER been ahead of the game!?!). Always? Otherwise there would be no need for documentation, if everything was in the code. Some people even start with writing docs and only then implement the actual code. Of course, it is not always the case (and some code, like Zend Engine, is so obvious that no docs are needed anyway ;) but documentation containing more insight and more content than the pure code is almost always the case, especially with properly documented code. So all I need to do is document this great new feature, hope no-one notices and then come screaming saying that it doesn't work as documented. Hmm. Possibly not a good way to make friends and influence people. This feature, along with property accessibility via some sort of read/write mechanism would be more useful to me than some other features (like cough-cough unicode cough-cough). It is something I am familiar with in other languages. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=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] php 5.2.4 test results reference
On Wed, 17 Oct 2007, jean jayet wrote: we would like to know whether at php org level there are any test results available / published / shared per OS (like Solaris, RH in particular) Not grouped, but we do have all the test results here: http://news.php.net/php.qa regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.2.4 test results reference
On Wed, 17 Oct 2007, jean jayet wrote: i have the following naive question : how can get a reference of test results smth to be able to find : such set of test case id MUST pass such set test case id MUST fail such set test case id skip if such extension missing etc,... Well, they should all pass - skipped tests depends totally on the configuration - I don't think we've any information on that at all. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.2.4 test results reference
Hi Derick many thks for the pointer going thru this link, there are hundreds of reports posted !!! can not go thru all of them most of the reports opened are for Linux didn't find any dedicated to Solaris (but for sure assuming they exist) parsing results, tests failed may vary (even if noticing same failed tests often occur) i have the following naive question : how can get a reference of test results smth to be able to find : such set of test case id MUST pass such set test case id MUST fail such set test case id skip if such extension missing etc,... thks Jean Derick Rethans wrote On 10/17/07 02:41 PM,: On Wed, 17 Oct 2007, jean jayet wrote: we would like to know whether at php org level there are any test results available / published / shared per OS (like Solaris, RH in particular) Not grouped, but we do have all the test results here: http://news.php.net/php.qa regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.2.4 test results reference
Well, they should all pass as catching 50 failed tests for php 5.2.4 / 5.11 for failed tests can someone tell the action to take ? - report a new bug at php org level for this php release ? - integration problem specific to OS (eg implementation specifities) ? - other ? rgds, Jean Derick Rethans wrote On 10/17/07 03:51 PM,: On Wed, 17 Oct 2007, jean jayet wrote: i have the following naive question : how can get a reference of test results smth to be able to find : such set of test case id MUST pass such set test case id MUST fail such set test case id skip if such extension missing etc,... Well, they should all pass - skipped tests depends totally on the configuration - I don't think we've any information on that at all. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] php 5.2.4 test results reference
Derick Rethans wrote: On Wed, 17 Oct 2007, jean jayet wrote: i have the following naive question : how can get a reference of test results smth to be able to find : such set of test case id MUST pass such set test case id MUST fail such set test case id skip if such extension missing etc,... Well, they should all pass - skipped tests depends totally on the configuration - I don't think we've any information on that at all. Jean - if the tests don't pass on your system it would be helpful if you could raise defects (http://bugs.php.net/) checking first to make sure that someone hasn't already done so, and make the .diff and .out files available. In some cases when we write tests it isn't possible to test on ALL platforms, so sometimes the tests may fail because they really should not pass on a specific platform (if so we will fix by adding a --SKIPIFF-- to the test case), sometimes it's because of an implementation difference - we can't tell till we see the output from the test. As Derick says, they should all pass :-) Zoe regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.2.4 test results reference
On 17.10.2007 18:05, jean jayet wrote: Well, they should all pass as catching 50 failed tests for php 5.2.4 / 5.11 for failed tests can someone tell the action to take ? Figure out the reason and act accordingly. If it's a problem caused by some Solaris-specific behaviour and we're missing a workaround for it (which is obvious for you) - send us a patch. If the test is wrong - report it to the php.qa list (or here). If there is a bug in PHP - report to bugs.php.net. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] exception policy for core
Hi, I remember that we discussed the question of exception throwing from core in the very early days of php 5, when the suggestion of turning all errors into exceptions first came up. I remember that we decided that exceptions should only be thrown from core on constructor errors by default. Along the lines of PDO, extensions could allow users to explicitly enable an exception mode. This popped up again as I picked up on IRC that the imagick extension is quite exception throwing happy. I do realize that this is a pecl extension, so maybe core rules do not apply (core-pecl relations should also be addressed ASAP if you ask me). Anywas, am I remembering things correctly? Is this still our policy? If not do we have (want?) a policy? Either way, could we get a decision (or the fact that we do not want a decision) added to the coding standards? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
On Wed, 17 Oct 2007, Lukas Kahwe Smith wrote: Hi, I remember that we discussed the question of exception throwing from core in the very early days of php 5, when the suggestion of turning all errors into exceptions first came up. I remember that we decided that exceptions should only be thrown from core on constructor errors by default. Along the lines of PDO, extensions could allow users to explicitly enable an exception mode. This popped up again as I picked up on IRC that the imagick extension is quite exception throwing happy. I do realize that this is a pecl extension, so maybe core rules do not apply (core-pecl relations should also be addressed ASAP if you ask me). Anywas, am I remembering things correctly? Is this still our policy? If not do we have (want?) a policy? In my opinion, this is still the policy that should be added to the CS. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Are there already any results on these checks? - Sebastian On 10/2/07, Andi Gutmans [EMAIL PROTECTED] wrote: Of course not (and I know we use import in a few places in ZF) which is why I want to see whether it makes sense to allow reserved words. The basic parsing rule would be easy but we need to check how many other areas this might affect. Wouldn't want to introduce any more inconsistencies. If it ends up being too much of a bother we can just end up using use. Andi -Original Message- From: Sebastian Nohn [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 11:16 PM To: Andi Gutmans Cc: Johannes Schlüter; Sebastian Bergmann; internals@lists.php.net Subject: Re: [PHP-DEV] T_IMPORT vs. T_USE Andi Gutmans wrote: Hi Johannes, Our preference would be to stick to import because I think the perception many will have of use is that it also includes files (just based on some other languages). That said I agree that compatibility would be an issue here. In fact it's even somewhat of an issue with namespace which is probably also used quite a bit esp. in relation to XML. I don't think people will care much about use vs. import perception-wise. But they will care a lot if it breaks their software. Just to name two popular products that will break (Johannes can for sure tell more, he googled for it): Serendipity Zend Framework. At least breaking the latter should not be your preference, I hope. - Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Are there already any results on these checks? Looks like we have the simple patch that allows to use import as method name, function name and class name. If we didn't discover any problems with it then import stays. -- 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] php 5.2.4 test results reference
we would like to know whether at php org level there are any test results available / published / shared per OS (like Solaris, RH in particular) Not grouped, but we do have all the test results here: http://news.php.net/php.qa In addition to what Derick said, there is a reference build and test failure at http://gcov.php.net Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Large file support for PHP
On Wednesday 17 October 2007 09:13:03 am Stanislav Malyshev wrote:
Of course. If there are two different PHP versions with different API
numbers, it's OK. What's less OK is when there's two PHP builds with
same API numbers which are binary incompatible.
right.
in the context of running debian (and by extension ubuntu) servers, you
wouldn't need to do anything if you were only using the pre-packaged
modules,
You mean - pre-packaged by Debian?
yeah. there are a number of precompiled modules provided by the debian php
package as well as other precompiled pecl packages available in the debian
archive. all of them are compiled against the same api, which is provided by
a php{4,5}-dev package, which you can install on your system if you want to
build your own modules as well.
Compatibility is not complicated if you deal with one machine where you
control everything and can rebuild everything from source. It starts to
get worse when you have a lot of machines on which you want to achieve
some kind of common environment. Having indistinguishable binary
incompatible PHP versions complicates things.
i'd say this has more to do with the administration habits of the individual
sysadmin. i for one would do my utmost to avoid ever finding myself in a
situation where i was compiling php (or any other moderately complex
software for that matter) from source on more than a couple different
OS/architecuture/distribution combinations, and instead try to consolidate
things. for example, using the distributions' precompiled packages,
backported packages, 3rd party packages, compiling once and nfs-mounting,
rsyncing, etc. but anyway, this is maybe getting a little side tracked
sean
signature.asc
Description: This is a digitally signed message part.
Re: [PHP-DEV] My musings on... a Solaris test platform
It would be interesting, yes. My university has been discontinuing the Solaris servers and now I only have access to an ancient Solaris 7 server. Even more interesting would be to get your patches to fix those bugs :) Thanks, Nuno - Original Message - From: Rob Thompson [EMAIL PROTECTED] To: internals@lists.php.net Sent: Tuesday, October 16, 2007 3:36 AM Subject: [PHP-DEV] My musings on... a Solaris test platform Hello, I've been thinking about Solaris support for PHP and some of the difficulty surrounding reproducing bugs under different Solaris OS versions, not to mention OS patch versions. I work at a University that heavily uses the PHP code base and have personally been actively working at trying to better the code in support of Solaris quirks/bugs. Would the following be a benefit to PHP developers, or not really worth the time, or somewhere in-between? A set of systems with up-to-date OSs, logins and GDB available to PHP developers to test and debug PHP under the following OSs: - Solaris 8 x86 - Solaris 8 sparc - Solaris 9 x86 - Solaris 9 sparc - Solaris 10 x86 - Solaris 10 sparc I could try to convince the powers that be to allow me to setup this environment, if there would be interest and use. Thanks, -Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object arithmetic
While looking at bug 42780: http://bugs.php.net/bug.php?id=42780 The only way not to lose precision is to explicitly cast the object to float or string, which just doesn't seem right to me. I'm not sure how this can be fixed - there should be some type used and many objects won't provide convertor to float... Anyway, it's probably not the best idea to rely on default conversion in this context - better to specify 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
[PHP-DEV] CVS Account Request: james
Assisting with maintenance of the documentation starting with user notes, and eventually editing of the manual itself. I have subscribed to the relevant mailing lists introduced myself, and Philip Olson has confirmed I should apply for CVS access here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object arithmetic
On 10/18/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: While looking at bug 42780: http://bugs.php.net/bug.php?id=42780 The only way not to lose precision is to explicitly cast the object to float or string, which just doesn't seem right to me. I'm not sure how this can be fixed - there should be some type used and many objects won't provide convertor to float... Anyway, it's probably not the best idea to rely on default conversion in this context - better to specify it. In this case, the proper solution is to force SimpleXML to cast values to strings, because, after all, XML has nothing but strings. Then engine would be able to cast the value further to float (as the last example in bug shows) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
