Re: [PHP-DEV] Revisit: zend_call_method() - n number of arguments
Hi! On 10/22/11 2:36 AM, Nathan Nobbe wrote: Hi, Another old issue I'd like to rehash with the upcoming release around the corner [1]. I patched 5.4 alpha2 for review [2]. I think better idea would be to add another API function (zend_call_method_ex?), that implements arbitrary argument count (either via array or via varargs) and make zend_call_method be a case of it, maybe. This way you don't have to break existing API and also don't have to stop at 4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] fclose(), file_put_contents(), copy() all fail to return false on error
Raised this 5 years ago.. http://marc.info/?l=php-internalsm=113998880315574w=2 Jared -Original Message- From: Tom Boutell [mailto:t...@punkave.com] Sent: 21 October 2011 20:40 To: PHP Internals Subject: [PHP-DEV] fclose(), file_put_contents(), copy() all fail to return false on error It appears that all three of these functions do not return false on error as they should if the stream is not flushed successfully. Yipes! https://bugs.php.net/bug.php?id=60110 Am I missing something here? It's especially bad with, say, an S3 stream wrapper that wants to write the whole thing as one HTTP request, but it could bite you with plain old files too. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- 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] fclose(), file_put_contents(), copy() all fail to return false on error
Slightly different - I agree that it's possible stream_close might need to signal a problem, but note that it is not responsible for flushing the output (because stream_flush is automatically called before stream_close). It would go a long, long, long way to at least respect the return value of stream_flush, especially since the bug in question can affect plain old files too, and code that doesn't return a proper value from stream_flush is already bombing for anyone who checks the result of calling fflush(). So all I'm asking is for fclose() and its friends (copy(), file_put_contents()...) to pay attention when flush fails. Those of us who are trying to write stable stream wrappers can then just keep in mind that stream_flush is where the action is. The lack of a return value from stream_close is annoying but not insurmountable. However if folks are really so worried that respecting the return values of the flush functions will break existing (bad) code, a php.ini option could be added: close_checks_flush And turned on by those of us who would really like to know if our files are really there (: On Sun, Oct 23, 2011 at 8:59 AM, Jared Williams jared.willia...@ntlworld.com wrote: Raised this 5 years ago.. http://marc.info/?l=php-internalsm=113998880315574w=2 Jared -Original Message- From: Tom Boutell [mailto:t...@punkave.com] Sent: 21 October 2011 20:40 To: PHP Internals Subject: [PHP-DEV] fclose(), file_put_contents(), copy() all fail to return false on error It appears that all three of these functions do not return false on error as they should if the stream is not flushed successfully. Yipes! https://bugs.php.net/bug.php?id=60110 Am I missing something here? It's especially bad with, say, an S3 stream wrapper that wants to write the whole thing as one HTTP request, but it could bite you with plain old files too. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revisit: zend_call_method() - n number of arguments
On Sun, Oct 23, 2011 at 12:50 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! On 10/22/11 2:36 AM, Nathan Nobbe wrote: Hi, Another old issue I'd like to rehash with the upcoming release around the corner [1]. I patched 5.4 alpha2 for review [2]. I think better idea would be to add another API function (zend_call_method_ex?), that implements arbitrary argument count (either via array or via varargs) and make zend_call_method be a case of it, maybe. This way you don't have to break existing API and also don't have to stop at 4. Hi Stas, That's what this patch does, there is a new function zend_call_method_multi, which takes an array, and I've revised zend_call method to use it. I could change it to varargs if that is preferred. thanks, -nathan
Re: [PHP-DEV] PHP 5.3.9 and is_a changes
Excerpts from Hannes Magnusson's message of Sat Oct 22 04:03:50 -0700 2011: On Fri, Oct 21, 2011 at 22:52, Clint Byrum cl...@ubuntu.com wrote: Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS release. LTS stands for Long Term Support, and it will be supported by Canonical for 5 years. Because of this, I really want to ship a version Wouldn't you rather want to include 5.4? 5.3 will no longer be supported by us shortly after your release.. So for the next 5 years you will be including something that is already unmaintained? I appreciate the sentiments of all who have weighed in on this, and I do want to make sure that we are paying attention to the greater PHP community's needs, not just Ubuntu's users. Shipping really old PHP versions is definitely not what we want to do. However, we do need to be able to support the release with updates. While 5.4 would probably mean more of those updates would be simple cherry picks from 5.4, it also means there would likely be a lot more of them, since 5.4.0 will undoubtedly be a more aggressive release than 5.3.9, and like any .0 release, it just won't have the exposure that 5.3.x has had. Also, we have 105 PHP applications in Ubuntu, 2 of which are in our main component (ganglia and nagios), which means they are supported by our security team and developers for the entire lifecycle of a release. Its not likely that we would be able to test all 105 of them with PHP 5.4 before the release date, which may mean some of them will be quite broken, and also require stable release updates to fix. Now, all of that said, I would love to have 5.4 as the version in 12.04. Since 103 of the 105 apps are community supported, that means we'd need a large community effort to make sure this is doable. Here's what would need to happen for 12.04 to ship with 5.4 instead of 5.3: 1) PHP needs to make a commitment to release very soon. Beta is fine for the first month or so of the cycle, but not more. 2) App developers need to commit to testing their apps on the dev release of Ubuntu. If people are interested, I'd be happy to set up a jenkins instance somewhere and give people write access to a bzr/svn/git tree of tests to run daily on the dev release. 3) We would need buy in from the rest of the server interested folks and the Ubuntu security team. The right time to discuss that is at the Ubuntu Developer Summit, which is coming up in Orlando, FL, US, just a week from Monday (starts Oct 31). 4) We need it *at least* in Debian experimental, preferrably in Debian unstable. I have not discussed this at all with the Debian PHP maintainers, so this is a big unknown. I've cc'd them for their comment. I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect this will happen naturally. So, I've registered a blueprint for UDS here: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 There's no guarantee we will be able to fit it in, so make sure to subscribe to it if you are interested in this topic. If any of you are interested in joining us virtually (or physically!) You can go here: https://launchpad.net/sprints/uds-p And register, then find it on the schedule at http://summit.ubuntu.com If you register for UDS-P with your available times, and subscribe yourself as essential for the blueprint, then the scheduler for the summit will make a best effort to put the session during the times you are available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
Hi Anthony: I will not comment on the original question of this thread, but felt obliged to point out some details where my understanding differs from what I understand from your explanation. On 22 Oct 2011, at 07:25, Anthony Ferrara wrote: Well, I have a few opinions on this that I think are worth sharing: 1. If this change is made, we no longer would have mixins, but would have regular multiple-inheritance (With all the issues associated with it). Note that I said mixins and not traits. That's because since these were implemented with state (member properties), they are not traits as implemented, but regular mixins. (Yet another gripe, but that's slightly off topic). Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Traits do not provide any provisioning for handling state. What you observe is that PHP is a very dynamic language when it comes to the definition of fields. And that is what traits also take into account. We do the minimal possible thing, to keep the WTF factor low, but there is no real support for state. And as someone else pointed out: the main difference is indeed the difference between linear application (mixins) and order-less composition (traits). There's a much bigger problem though. How would you solve the problem where a class uses a trait that implements an interface, but you don't pull one of the methods through (for example, you exclude it in the use clause)? The relevant part of the RFC: https://wiki.php.net/rfc/horizontalreuse#conflict_resolution We abandoned the idea of an explicit exclude operator long ago. (I think it was never in the PHP SVN.) Thus, the situation you describe cannot occur in the sense that a method is missing from the class. However, you can of course provide incompatible method implementations. (Which does not make traits any different from any other way to implement an interface.) Best regards 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
[PHP-DEV] git conversion proposal
Hi! ESR proposes his help to OSS projects in converting SVN projects to Git: http://esr.ibiblio.org/?p=3839 Just thought it might be interesting. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
