Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
Zeev has an excellent point here, my own research shows that 5.4, a year after release had somewhere in the 2% adoption rate. The major reason being is the lack of a stable, production ready op-code cache. To release 5.5 without a good solution for that problem, would not make the situation better, if anything it would make it very intimidating to users to jump 2-3 versions directly to 5.6. Thus leaving us with a massive user base running legacy, unsupported versions containing unresolved bugs and vulnerabilities. Something, which I don't think would be a very good thing for the future of PHP. Ultimately, I think it is better to wait a month or two (if that is what it takes) and have a solid release people can safely upgrade their production environments to, rather than strictly adhere to a set release cycle and delivery a partial solution. On Thu, Feb 28, 2013 at 5:21 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Thursday, February 28, 2013 12:17 AM To: Rasmus Lerdorf Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution Now, about the yearly release, every single person I talked to love it and want us to keep with this cycle, as well as the more frequent bugs fixes releases. One thing we have to slightly change is to push too many new features in each of them, but we will get there. I'm not sure how many people you've spoken to and what their profile is, but reality shows a very different picture: 481004 PHP/5.2.17 280342 PHP/5.3.8 271156 PHP/5.2.6-1+lenny16 146342 PHP/5.2.9 133818 PHP/5.2.6 125550 PHP/5.3.10 109513 PHP/5.2.6-1+lenny13 106320 PHP/5.2.5 102412 PHP/5.2.14 81221 PHP/5.2.6-1+lenny9 These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x, in case you're wondering, shows up on the 44th place, with a bit over 20K deployments worldwide (5.4.11). With yearly release cycles, we may make the lives of a few users more enjoyable and with more rapid access to new features; But for the vast majority, we're actually making lives worse: 1. Framework app developers can't really rely on new features anyway, since nobody has those new versions installed. Just two years ago - aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's even though PHP 5.3 brought some revolutionary features to the mix (which 5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and we can assume that it'd take many years before other apps feel comfortable requiring a higher version than 5.3.x as a prerequisite. 2. Users who want to stay secure have to constantly upgrade, since support lifetimes have been trimmed down substantially (effectively, 3 years from release; and considering nobody upgrades on to an x.y.0 version, it's typically way less than that). We can already project that based on the current frequency, people who install PHP 5.4 today will have less than two years-worth of lifetime before they're forced to upgrade, or be left unsupported. 3. For the ecosystem in general, we're creating lots of fragmentation. All in all, I think the people who like the yearly release cycle are first and foremost bleeding edge individual developers, and not people who are a part of larger projects, or that actually have to worry about production apps working uninterrupted. Zeev -- 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4 was. Today, right now, there exists at least one stable open source opcode cache. 5.4 had none for many months after release. So I'm not sure if the same pressures exist. If you are referring to APC as the stable cache, that unfortunately is not entirely correct, it is still relatively easy to crash APC unless some work-arounds are applied. I was speaking to a several people at the conference just yesterday and they were indicating frequent crashes with APC, the work-arounds appear to have solved their issues, but those are not exactly obvious. The discussion now is if we delay 5.5 to spend the time pulling it in core. But either way (in core or not), ZO+ is open and working on 5.5 alpha. So we could skip the core import, and just ship it today as gold, and it would be adoptable straight away (unlike how 5.4 was). Well the question around the delay, is what is the negative consequence of the delay, versus the advantage of having a built-in opcode cache shipped as part of 5.5 which is likely to give many people an impetuous to upgrade from their current 5.2/5.3 install. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
Well the question around the delay, is what is the negative consequence of the delay, versus the advantage of having a built-in opcode cache shipped as part of 5.5 which is likely to give many people an impetuous to upgrade from their current 5.2/5.3 install. If we get to get it stable in a relatively short period. It is hard with APC, which is available open since its very 1st day, it is harder with o+, new code, new algos, new settings, etc. If ZO+ was a brand new code, I'd agree with you 100%. However, it is an existing solution that has been used in a wild in quite some time an limited empirical evidence shows that it works somewhat better than APC in most cases from stability perspective. Ultimately, peoples opinions will drive the decision, just wanted to share my perspective based on personal experience and feedback that I got from people trying to use 5.4 in production and their expressed pains... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
If you are referring to APC as the stable cache, that unfortunately is not entirely correct, it is still relatively easy to crash APC unless some work-arounds are applied. I was speaking to a several people at the conference just yesterday and they were indicating frequent crashes with APC, the work-arounds appear to have solved their issues, but those are not exactly obvious. Even more evidence that the situation for 5.5 is not the same as for 5.4, as a stable cache does exist for 5.5, when it still doesn't for 5.4... Wouldn't that make it ever so important to address this issue before releasing another version, since production use of PHP pretty much requires use of an opcode cache if you want any degree of performance? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
The APC issues are somewhat APC specific in most cases, they often revolve around memory utilization issues and garbage collection. Some of the work-arounds involve ensuring APC always has extra memory to prevent fragmentation. When fragmentation goes about 35-40% clearing out the entire cache to prevent increase in fragmentation which in many cases can reduce stability. Loading large number of files in parallel is another thing that frequently can negatively impact APC, doing pre-loading or staggering the loading process is the work-around that typically prevents issues. On Thu, Feb 28, 2013 at 2:16 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! If you are referring to APC as the stable cache, that unfortunately is not entirely correct, it is still relatively easy to crash APC unless some work-arounds are applied. I was speaking to a several people at the conference just yesterday and they were indicating frequent crashes with APC, the work-arounds appear to have solved their issues, but those are not exactly obvious. Do we have those ways and work-arounds recorded somewhere? It would be a very good idea to have tests for O+ to ensure there are no problems in these areas (or if there are, to fix them :). My experience suggests opcode cache solutions often tend to have issues in the same areas, so I think it'd be very useful. -- 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] [RFC] ICU UConverter implementation for ext/intl
After the updates it looks really good, very handy functionality to have. On Tue, Oct 30, 2012 at 6:18 PM, Sara Golemon poll...@php.net wrote: With the exception of renaming the UConverter::UCNV_* constants to remove the UCNV_ prefix, I believe I've addressed the concerns thus far. ((Waiting to hear if anyone else wants to weigh in on the contants)) The RFC has been updated accordingly.+ -- 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] Let parse_str() parse more than max_input_vars args
Sounds like a least dangerous way of solving the problem to me. The only issue I can see with this fix is what would happen is if after the PG(max_input_vars) = max_vars; call the request got interrupted in persistent environment such as Apache (mod_php). Wouldn't that means that for subsequent requests the value would not be equal to the one set by the user? On Wed, Mar 14, 2012 at 3:42 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: It is somewhat unintuitive that parse_str() is subject to the max_input_vars limitation and there are sites that use parse_str() to parse things that aren't directly coming from user query args. There arr two ways to solve this. We could add an optional max_vars arg something along these lines: https://gist.github.com/2038870 The other way to solve this would be to make max_input_vars PHP_INI_ALL and then just let people ini_set() their way around the limit. The one drawback with the optional arg approach is that since parse_str() is a thin layer on top of the query string parser, the error if you exceed the passed max_vars talks about the ini setting which in this case wouldn't really be correct and fixing that would be complicated. -Rasmus -- 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] Upgrade cURL extension
The oop interface to cURl is already available, take a look at http://pecl.php.net/package/pecl_http extension. It provides OOP interface and takes care of many of the input preparation or output parsing tasks normally you need to do in PHP when working with cURL. On Sat, Mar 10, 2012 at 12:49 PM, Simon Schick simonsimc...@googlemail.com wrote: 2012/3/10 Reindl Harald h.rei...@thelounge.net: Am 10.03.2012 18:28, schrieb Simon Schick: I'd like to see a new interface for curl in php ... I have no special idea how, but I heard from several people that they pretty much don't like the way curl is implemented in php. many other people would not like to break their perfect working code! Hi, Reindl I do not mean to drop the implementation as it is right now - but think of something different for the future. If there would be an additional implementation it would probably be like mysqli, where you have an oop-implmentation and a non-oop. Bye Simon -- 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] Upgrade cURL extension
Stas, That could work for people who don't have cURL built-in to their PHP version, but otherwise create a symbol conflict. On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Anthony,
My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting. First off, here's
the patch:
Directly apply-able without re2c:
https://gist.github.com/2004623
Removing generated files (requires re2c to compile):
https://gist.github.com/2004650
It's a POC, but it mostly works. There is one known issue: passing a
class implementing __toString to a string hinted function will raise a
segmentation fault. There's also an issue of not separating the
argument on cast yielding to reference whether indicated or not, but
that should be easy to fix (it's just issuing a SEPARATE_IF_NOT_REF in
the cases where it would cast)... I'll work on cleaning it up, but I
wanted to show the concept before investing too much work...
So, basically, there are 4 new parameters:
bool
int
float
string
The casting vs error rules are identical to zend_parse_parameters. So:
function fooi(int $i) { var_dump($i); }
fooi(1); // int(1)
fooi(1.5); // int(1)
fooi(1); // int(1)
fooi(1abc); // int(1) + notice about non-well-formed numeric
fooi(foo); // E_RECOVERABLE_ERROR
fooi(true); // int(1)
fooi(array()); // E_RECOVERABLE_ERROR
fooi($obj); // E_RECOVERABLE_ERROR
function foob(bool $b) { var_dump($b); }
foob(1); // bool(true)
foob(1.5); // bool(true)
foob(1); // bool(true)
foob(abc); // bool(true)
foob(true); // bool(true)
foob(array()); // E_RECOVERABLE_ERROR
foob($obj); // E_RECOVERABLE_ERROR
function foos(string $s) { var_dump($s);
foos(1); // string(1)
foos(1.5); // string(1.5)
foos(1); // string(1)
foos(true); // string(1)
foos(array()); // E_RECOVERABLE_ERROR
foos(new StdClass); // E_RECOVERABLE_ERROR
foos($objImpl__toStringORcast_object); // string(result)
Float works like int, so I won't list it out here...
So, what do you think?
Thanks,
Anthony
--
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] [RFC] discussions, about a 5.3 EOL
Option #1 seems like a good way to go to me. On Fri, Mar 2, 2012 at 7:34 AM, Pierre Joye pierre@gmail.com wrote: hi, It should have been done before 5.4.0 was out, but better late than never. I put together four options here: https://wiki.php.net/rfc/php53eol I'm in favor of option #1, as it gives enough time to our users to migrate by reducing the maintenance period to only one year. Suggestions or comments welcome, 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
The change is inside 5.4 version which adjust breaks BC. --- Ilia On Dec 27, 2011 10:15 AM, Patrick ALLAERT patrickalla...@php.net wrote: 2011/12/27 Ilia Alshanetsky i...@ilia.ws: I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. As mentioned earlier, I don't like this option very much but at least it solves the BC problem. Do you have any other proposal to share? Opposing to that without proposing a solution kinda looks like I don't bother if it breaks BC. -- Patrick
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethans der...@php.net wrote: On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? I'd vote for a (REQUEST_TIME_FLOAT), as MSEC is not what it really does. Depending on the time and precision it might not show miliseconds f.e. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
In most instances integers and floats can be used interchangeably, which is why the patch was written in the way that it was. In the few rare cases (int) cast takes care of the trick, there is a substantial benefit for timings etc... to have higher precision timestamp available at no additional cost. Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. On Sat, Dec 24, 2011 at 10:07 AM, Pierre Joye pierre@gmail.com wrote: On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke a...@ez.no wrote: Yes, this is the one from Zeta Components MvcTools. In eZ Publish it was db based session gc using REQUEST_TIME and compatibility for potential extensions that might have used this variable via eZ Publish api: https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45 In both cases a (int) was added in front of the variable to make sure it still behaves the same, so not a big deal. But as also mentioned, changes like this requires patching to be compatible with 5.4. So unless this is done to be inline with some standard on such a server variable, I would suggest placing microtime on a separate server variable (since it is indeed useful to have it for time accumulators and performance metrics). Right, and that's why I would be in favour of a BC change, maybe by introducing a REQUEST_TIME_FLOAT instead, so people willing to use the float version can still have it while the existing code needs no change. Adding Ilia (who made that change) and the RMs to the list. 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] Results of testing ZF against PHP 5.4.0RC1
I agree with Stas' point there is really no need to force people do the while (ob_get_level()) ob_end_clean(); loop or force people to use the @ob_end_clean(); to avoid notices. If there are no buffers to clear it should be a noop, without any notices being raised. On Fri, Nov 18, 2011 at 12:04 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! First of all, ob_clean() and ob_end_clean() will raise the same notice even in PHP 5.3. It seems inconsistent to me to treat these three differently, so in that regard, PHP 5.4 is actually fixing behavior (although arguably the other way to approach the problem is to remove the notice from all three of them). I don't think ob_end_clean() should produce notices, otherwise it leads to needless boilerplate code like: if(ob_get_evel()0) ob_end_clean(); while you could just write ob_end_clean() and be done with it. ob_clean() is trickier since it's supposed to leave buffer in place, but for functions that are supposed to remove the buffer warning doesn't add any value, only makes people write uglier code. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #60038 SIGALRM cause segfault in php_error_cb
Unless you are deleting thousands of files in a tight loop, the overhead involved won't make any difference for your application. In general your application is throwing many errors, even benign E_STRICT or E_NOTICE you are already incurring a performance hit. On Mon, Oct 17, 2011 at 3:49 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! On 10/16/11 5:54 PM, Sebastian Bergmann wrote: Such a performance regression sounds like an appropriate punishment to me for deploying bad code ;-) By bad code you mean not obsessively checking for stuff that is of no importance to them as programmers and is only required because language implementers decided to go BD on their users? ;) I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null. I think it's bad we make people do that. and there are cases when you can't avoid triggering errors (like trying to delete delete a while which can be deleted concurrently) so your only option is to suppress them and handle the result based on the return value of the statement. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Ternary operator performance improvements
Seems like a good patch, +1 from me on inclusion into 5.4/HEAD.
On Fri, Oct 14, 2011 at 2:08 PM, Arnaud Le Blanc arnaud...@gmail.com wrote:
Hi,
I've already posted this patch and it has since been reviewed and improved.
I'm re-posting it for discussion before eventually commiting it.
The ternary operator always copies its second or third operand, which is very
slow compared to an if/else when the operand is an array for example:
$a = range(0,9);
// this takes 0.3 seconds here:
for ($i = 0; $i 500; ++$i) {
if (true) {
$b = $a;
} else {
$b = $a;
}
}
// this takes 3.8 seconds:
for ($i = 0; $i 500; ++$i) {
$b = true ? $a : $a;
}
I've tried to reduce the performance hit by avoiding the copy when possible
(patch attached).
Benchmark:
Without patch: (the numbers are the time taken to run the code a certain
amount of times)
$int = 0;
$ary = array(1,2,3,4,5,6,7,8,9);
true ? 1 : 0 0.124
true ? 1+0 : 0 0.109
true ? $ary : 0 2.020 !
true ? $int : 0 0.103
true ? ${'ary'} : 0 2.290 !
true ?: 0 0.091
1+0 ?: 0 0.086
$ary ?: 0 2.151 !
${'var'} ?: 0 2.317 !
With patch:
true ? 1 : 0 0.124
true ? 1+0 : 0 0.195
true ? $ary : 0 0.103
true ? $int : 0 0.089
true ? ${'ary'} : 0 0.103
true ?: 0 0.086
1+0 ?: 0 0.159
$cv ?: 0 0.090
${'var'} ?: 0 0.089
The array copying overhead is eliminated. There is however a slowdown in some
of the cases, but overall there is no completely unexpected performance hit as
it is the case currently.
What do you think ? Is there any objection ?
Best regards,
--
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] #60038 SIGALRM cause segfault in php_error_cb
Seems like a fine solution, performance loss would occur only when error happens... On Tue, Oct 11, 2011 at 5:30 AM, Laruence larue...@php.net wrote: Hi: I filed a bug about SIGALRM(or SIGPROF) has chance to cause segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038 do you think this is worth fixing (in 5.4 trunk)? (as zend_signal was introduced, and this fix will cost litte perf). thanks -- Laruence Xinchen Hui http://www.laruence.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] APC in 5.4
The agreement to include apc in 5.4 is an old one, unfortunately the action of doing was just missed. Also, inclusion of the extension won't break any code since it is self contained... On Thu, Sep 8, 2011 at 9:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/8/11 6:04 PM, Kalle Sommer Nielsen wrote: This have been a while since we had the discussions about APC in 5.4 (or in general extensions to move in and out of the Core, but more about that in another thread). Not saying anything specifically about APC, I think it is way too late to propose major features for 5.4 when we're days before beta. So if it's 5.4, it's not 5.4.0 for sure. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
Revert sounds find to me, the change was indeed to fix the test. On Wed, Aug 31, 2011 at 6:58 AM, Christian Stocker christian.stoc...@liip.ch wrote: On 31.08.11 12:25, Laruence wrote: Hi: I think you should not commit untill ask ilia for the reason of previous change, sure, but my guess is he just fixed the code to pass the test, but IMHO the test was wrong (and my patches fixes that). ilia? chregu thanks 2011/8/31 Christian Stocker christian.stoc...@liip.ch: Hi Here's my proposed patch https://gist.github.com/1183212 If noone objects, I'll commit it soon chregu On 31.08.11 11:39, Christian Stocker wrote: On 31.08.11 09:47, Stas Malyshev wrote: Hi! For simplexml test (ext/simplexml/tests/bug48601.phpt), it looks like Ilia reverted the fix for bug #48601 with this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311870r2=311874 I'm not sure what simplexml is supposed to return in each case, the tests seem to be contradictory. Anybody knows what is the right thing to do here? Ilia fixed test 0008.phpt with that, but for some reason an XPath of *** isn't considered invalid by libxml (but ** is, don't ask me why ;)). I'd say if libxml doesn't think the XPath expression is invalid, we should return an empty array and not false. With DOM exactly that happens. I therefore vote for reverting Ilia's patch mentioned above. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE -- 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] [VOTE] Choosing a distributed version control system for PHP
If we do decide to make a VCS change the vote should be fairly one sided for option of choice as this has a fairly broad impact on our development process. On Wed, Aug 24, 2011 at 5:03 PM, David Soria Parra d...@php.net wrote: Hi Internals,, after 3 weeks of discussion, I think we are ready to start voting on the DVCS RFC. If you think something is missing or should be explained in more detail, let me know. Votes can be found here: https://wiki.php.net/rfc/dvcs/vote The RFC can be found here: https://wiki.php.net/rfc/dvcs Voting will be opened for 2 weeks and end on Sept. 7 at 12 pm. - David -- 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] is_a() triggers __autoload() in 5.3.7
The fix looks good, Dmitry can you please review it, if it is good let's get it into 5.3.8 On Mon, Aug 22, 2011 at 6:33 AM, Kalle Sommer Nielsen ka...@php.net wrote: 2011/8/22 Mads Lie Jensen m...@gartneriet.dk: On Mon, 22 Aug 2011 10:00:11 +0200, hannes.magnus...@gmail.com (Hannes Magnusson) wrote: I can reproduce that in 5.3-svn and 5.4-svn. Please file a bug report for it, this should probably be fixed in 5.3.8 too. Done: Bug #55475 is_a() triggers autoloader I have attached a simple one liner patch to the report, which like Hannes said, should go into 5.3.8 to keep BC. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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
[PHP-DEV] PHP 5.3.7 Released!
The PHP development team would like to announce the immediate availability of PHP 5.3.7. This release focuses on improving the stability of the PHP 5.3.x branch with over 90 bug fixes, some of which are security related. Security Enhancements and Fixes in PHP 5.3.7: * Updated crypt_blowfish to 1.2. (CVE-2011-2483) * Fixed crash in error_log(). Reported by Mateusz Kocielski * Fixed buffer overflow on overlog salt in crypt(). * Fixed bug #54939 (File path injection vulnerability in RFC1867 File upload filename). Reported by Krzysztof Kotowicz. (CVE-2011-2202) * Fixed stack buffer overflow in socket_connect(). (CVE-2011-1938) * Fixed bug #54238 (use-after-free in substr_replace()). (CVE-2011-1148) Key enhancements in PHP 5.3.7 include: * Upgraded bundled Sqlite3 to version 3.7.7.1 * Upgraded bundled PCRE to version 8.12 * Fixed bug #54910 (Crash when calling call_user_func with unknown function name) * Fixed bug #54585 (track_errors causes segfault) * Fixed bug #54262 (Crash when assigning value to a dimension in a non-array) * Fixed a crash inside dtor for error handling * Fixed bug #55339 (Segfault with allow_call_time_pass_reference = Off) * Fixed bug #54935 php_win_err can lead to crash * Fixed bug #54332 (Crash in zend_mm_check_ptr // Heap corruption) * Fixed bug #54305 (Crash in gc_remove_zval_from_buffer) * Fixed bug #54580 (get_browser() segmentation fault when browscap ini directive is set through php_admin_value) * Fixed bug #54529 (SAPI crashes on apache_config.c:197) * Fixed bug #54283 (new DatePeriod(NULL) causes crash). * Fixed bug #54269 (Short exception message buffer causes crash) * Fixed Bug #54221 (mysqli::get_warnings segfault when used in multi queries) * Fixed bug #54395 (Phar::mount() crashes when calling with wrong parameters) * Fixed bug #54384 (Dual iterators, GlobIterator, SplFileObject and SplTempFileObject crash when user-space classes don't call the parent constructor) * Fixed bug #54292 (Wrong parameter causes crash in SplFileObject::__construct()) * Fixed bug #54291 (Crash iterating DirectoryIterator for dir name starting with \0) * Fixed bug #54281 (Crash in non-initialized RecursiveIteratorIterator) * Fixed bug #54623 (Segfault when writing to a persistent socket after closing a copy of the socket) * Fixed bug #54681 (addGlob() crashes on invalid flags) * Over 80 other bug fixes. Windows users: please mind that we do no longer provide builds created with Visual Studio C++ 6. It is impossible to maintain a high quality and safe build of PHP for Windows using this unmaintained compiler. For Apache SAPIs (php5_apache2_2.dll), be sure that you use a Visual Studio C++ 9 version of Apache. We recommend the Apache builds as provided by ApacheLounge. For any other SAPI (CLI, FastCGI via mod_fcgi, FastCGI with IIS or other FastCGI capable server), everything works as before. Third party extension providers must rebuild their extensions to make them compatible and loadable with the Visual Studio C++9 builds that we now provide./p All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.7RC5 Released for Testing
The fifth and final release candidate of 5.3.7 was just released for testing and can be downloaded here: https://downloads.php.net/ilia/php-5.3.7RC5.tar.bz2 (md5sum: 2604b92812e213287fa0fbc5d61223db) https://downloads.php.net/ilia/php-5.3.7RC5.tar.gz (md5sum: 2d3315be5ef7ab90ca359978f36c2001) The Windows binaries are available at: http://windows.php.net/qa/ This RC is in place to validate the changes resulting from various code adjustments made to address issues identified by static analysis. If no issues arise the final release will be made next week. To make sure we can finally get 5.3.7 out of the door, I would like to ask that all developers refrain from making commits into the 5.3 branch, until the final release is made (especially those on working on Coverity identified issues). PHP 5.3.7 is focused on improving the stability and security. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC5/NEWS?revision=HEADview=markup Windows users please mind that we don't provide VS6 builds anymore since PHP 5.3.6. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coverity Scan
Scott, I've looked through most of the changes (some are even mine ;-) ) and they seem to be fairly harmless initialization tweaks etc... As it stands I think we should be in good shape to package 5.3.7 on Wed and finally get it out of the door. On Mon, Aug 8, 2011 at 3:18 AM, Scott MacVicar sc...@macvicar.net wrote: On 6 Aug 2011, at 20:07, Rasmus Lerdorf wrote: Coverity has run a new scan of trunk and there are a lot of valid issues. You have probably noticed that I have started to fix some of them, but there are 500+ to go, so I could use some help. The following people already have Coverity accounts: andi, antony, colder, derick, dmitry, helly, iliaa, jcogg, joey, kmori, mike, nickpj, nlopess, phoddie, rui, sas, scottmac, sean, sesser, slif, steph, tgoldstein, thiago, wez and zeev If you would like to help out and you don't have an account, please send me an email or catch me on irc and I will get you set up. Once you have an account, go to: http://scan.coverity.com/rung2.html And click on the Sign in link next to PHP If you start working on fixing one of these, please assign it to yourself first within the Coverity UI so others will know. All these changes to PHP 5.3 scare me, I was hoping we'd see 5.3.7 released sooner but after all these changes I think we'll need some more RCs out. Thoughts ilia? - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build broken: ext/xsl/xsltprocessor.c
Thanks, I've just applied a fix for this. On Mon, Aug 8, 2011 at 10:45 AM, Damien Tournoud d...@damz.org wrote: Just FYI, this commit broke the build: http://svn.php.net/viewvc?view=revisionrevision=314515 One occurrence as been missed in: ext/xsl/xsltprocessor.c: DOM_RET_OBJ(rv, (xmlNodePtr) newdocp, ret, NULL); Reference: https://drupaltesting.org/jenkins/job/php5.4-build/235/ Damien -- 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] Build broken: ext/xsl/xsltprocessor.c
Different error, fixed now as well. On Mon, Aug 8, 2011 at 12:39 PM, Damien Tournoud d...@damz.org wrote: Thanks for the fix, but it is still failing in xsltprocessor.c, as far as I can tell: /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c: In function 'xsl_ext_function_php': /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:242: warning: pointer targets in initialization differ in signedness /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:252: warning: pointer targets in assignment differ in signedness /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:272: warning: pointer targets in passing argument 1 of 'xmlStrdup' differ in signedness /usr/include/libxml2/libxml/xmlstring.h:41: note: expected 'const xmlChar *' but argument is of type 'char *' /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:275: warning: pointer targets in passing argument 3 of 'xmlNewDocNode' differ in signedness /usr/include/libxml2/libxml/tree.h:782: note: expected 'const xmlChar *' but argument is of type 'char *' /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:277: warning: pointer targets in passing argument 3 of 'xmlNewDocNode' differ in signedness /usr/include/libxml2/libxml/tree.h:782: note: expected 'const xmlChar *' but argument is of type 'char *' /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:283: warning: passing argument 4 of 'php_dom_create_object' from incompatible pointer type /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/../dom/xml_common.h:57: note: expected 'struct dom_object *' but argument is of type 'struct zval *' /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:283: error: too many arguments to function 'php_dom_create_object' Full log: https://drupaltesting.org/jenkins/job/php5.4-build/237/consoleFull Damien On Mon, Aug 8, 2011 at 6:06 PM, Ilia Alshanetsky i...@prohost.org wrote: Thanks, I've just applied a fix for this. On Mon, Aug 8, 2011 at 10:45 AM, Damien Tournoud d...@damz.org wrote: Just FYI, this commit broke the build: http://svn.php.net/viewvc?view=revisionrevision=314515 One occurrence as been missed in: ext/xsl/xsltprocessor.c: DOM_RET_OBJ(rv, (xmlNodePtr) newdocp, ret, NULL); Reference: https://drupaltesting.org/jenkins/job/php5.4-build/235/ Damien -- 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] 5.3.7 is there a RC5 coming soon?
Unless something changes, I think we are going to go from RC4 to final release. On Wed, Aug 3, 2011 at 8:29 PM, James Yu jym2...@gmail.com wrote: Thanks! -- 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
[PHP-DEV] PHP 5.3.7RC4 Released for Testing
The fourth and hopefully final release candidate of 5.3.7 was just released for testing and can be downloaded here: https://downloads.php.net/ilia/php-5.3.7RC4.tar.bz2 (md5sum: 143ae4c3c5df93e2a9efae532cb51790) https://downloads.php.net/ilia/php-5.3.7RC4.tar.gz (md5sum: 8543604a0f171424c73ccaff5061f7ba) The Windows binaries are available at: http://windows.php.net/qa/ There were a few important fixes made since RC3 and this new RC is designed to validate that these fixes have not introduced any regressions. The intent is that this is the final release candidate before the final release, which if all goes well will follow in 2 weeks. PHP 5.3.7 is focused on improving the stability and security. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC4/NEWS?revision=HEADview=markup Windows users please mind that we don't provide VS6 builds anymore since PHP 5.3.6. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote results
Stas, On the Remove magic quotes there seems to be an overwhelming support from PHP Core and the community for removing it. Any reason there is no definitive decision on the topic? On Sun, Jul 17, 2011 at 5:08 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Here are the results of the votes. I've split them into PHP Group - people that have write access to the PHP code, based on SVN karma algorithm, and Community - all the rest. Here it goes: Declare PHP/php as namespace reserved for PHP internals Votes: 57 total, 20 PHP Core, 37 community For option PHP: PHP group support: 15 (75%), community: 28 (75%) For option php: PHP group support: 14 (70%), community: 26 (70%) This is clearly accepted. As it's docs only change, let's update the docs accordingly. 3 people from PHP group voted against: auroraeosrose,cataphract,kalle. It'd be interesting to know why, didn't hear anything on the list AFAIR. Make primitive types (string, bool, int, etc.) reserved words - Removed for BC reasons, so no reason to count vote results. Add E_STRICT to E_ALL - Votes: 58 total, 23 PHP Core, 35 community Every single voter supported it, nuff said. Add option to disable POST data processing -- Votes: 58 total, 23 PHP Core, 35 community Again, accepted unanimously. Support binary notation (0b1010101) Votes: 56 total, 21 PHP Core, 35 community Unanimous again! Remove magic quotes Votes: 54 total, 21 PHP Core, 33 community For removal: PHP group support: 18 (85%), community: 32 (96%) Again, 3 people voted against: derick,salathe,zeev. Any comments? Array short syntax --- Votes: 61 total, 23 PHP Core, 38 community First option (just brackets): PHP group support: 15 (65%), community: 28 (73%) Second option (brackets and colons): PHP group support: 2 (8%), community: 7 (18%) Against both: PHP group support: 6 (26%), community: 3 (7%) I think we can deem the first option passed, but not the second one. Callable type check --- Votes: 51 total, 21 PHP Core, 30 community For callable: PHP group support: 13 (61%), community: 21 (70%) For callback: PHP group support: 8 (38%), community: 10 (33%) Against both: PHP group support: 5 (23%), community: 1 (03%) We have clear majority here for implementing it, but preference on the name is less clear. Personally, I strongly urge that proposer would consider not to add another mess in our documentation and call it what it was always called in our docs. Otherwise, I guess documentation team should go and fix all our docs to say callable now. Change rebinding behavior of closures - Votes: 33 total, 10 PHP Core, 23 community PHP group support: 10 (100%), community: 22 (95%) Votes for this one are sparse, but unanimously in support. If we have no BC issues there, it's in. foreach adds list support -- Votes: 32 total, 11 PHP Core, 21 community For: PHP group support: 1 (9%), community: 8 (38%) Rejected, at least for 5.4, sorry. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.7RC3 Released for Testing
The third and hopefully final release candidate of 5.3.7 was just released for testing and can be downloaded here: https://downloads.php.net/ilia/php-5.3.7RC3.tar.bz2 (md5sum: 0ad46340ca3d4319ab10eac4a3978ae0) https://downloads.php.net/ilia/php-5.3.7RC3.tar.gz (md5sum: eab0329078f74f6c8fe5abcf6943b262) The Windows binaries are available at: http://windows.php.net/qa/ Given the volume of fixes since RC2 it was deemed necessary to make another to ensure that there are no regressions. The intent is that this is the final release candidate before the final release, which if all goes well will follow in 2 weeks. PHP 5.3.7 is focused on improving the stability and security. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC3/NEWS?revision=HEADview=markup Windows users please mind that we don't provide VS6 builds anymore since PHP 5.3.6. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.7RC2 Released for Testing
The second release candidate of 5.3.7 was just released for testing and can be downloaded here: https://downloads.php.net/ilia/php-5.3.7RC2.tar.bz2 (md5sum: 1f4fba48807d5d6236b24ca1f1b63e69) https://downloads.php.net/ilia/php-5.3.7RC2.tar.gz (md5sum: d57c2d49d4e9c8a90d31068d88605ef2) The Windows binaries are available at: http://windows.php.net/qa/ Given the small number of changes since the last RC, it is likely a final version will be released in 2 weeks. If it is not, a third release candidate will be available in 2 weeks. PHP 5.3.7 is focused on improving the stability and security. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. To find out what was changed since the last release please refer to the NEWS file found within the archive or on http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC2/NEWS?revision=HEADview=markup Windows users please mind that we don't provide VS6 builds anymore since PHP 5.3.6. When using the openssl extension please mind a known regression which might lead to a performance degression. This regression will be fixed with RC2 and the final release. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
+1, seems useful. On Mon, Jun 20, 2011 at 8:02 AM, Robert Eisele rob...@xarg.org wrote: Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
As long as it works on a premise that a string is a byte array and each element represents 1 byte, +1 from me. On Mon, Jun 20, 2011 at 7:27 AM, Robert Eisele rob...@xarg.org wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I think, adding features like this persuades the one or the other PHP user to upgrade to 5.4. Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
The crash is now fixed as well. On Fri, Jun 3, 2011 at 2:41 AM, Felipe Pena felipe...@gmail.com wrote: 2011/6/2 Felipe Pena felipe...@gmail.com Hi, 2011/6/2 Michael Maclean mich...@no-surprises.co.uk On 02/06/11 18:20, Gustavo Lopes wrote: Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org escreveu: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. Is there any advantage in killing it as opposed to simply not use it? I think he meant just replacing it in this patch. Just to inform, with the patched applied in trunk we have 4 SIGSEGVs with ext/pcntl tests: pcntl_alarm() [ext/pcntl/tests/pcntl_alarm.phpt] pcntl_signal() [ext/pcntl/tests/pcntl_signal.phpt] pcnt_signal_dispatch() [ext/pcntl/tests/pcntl_signal_dispatch.phpt] Closures as a signal handler [ext/pcntl/tests/signal_closure_handler.phpt] And 1 test hanging: ext/pcntl/tests/002.phpt Ok, already fixed. There is only a test failing due a behavior change: $ cat ext/pcntl/tests/pcntl_signal.diff 009+ Fatal error: Error installing signal handler for -1 in /home/felipe/dev/phptrunk/ext/pcntl/tests/pcntl_signal.php on line 10 009- Warning: pcntl_signal(): Error assigning signal %s 010- bool(false) 011- 012- Warning: pcntl_signal(): Error assigning signal %s 013- bool(false) 014- 015- Warning: pcntl_signal(): not callable is not a callable function name error in %s 016- bool(false) 017- ok -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, I would suggest to kill the TSRMLS_FETCH while being at it. They are horribly slow and a couple of them can be replaced by the TSRMLS_DC/CC, if I'm not mistaken. For the windows side, I do not have the time to do the equivalent, so if you commit the patch to trunk first so I can fix the build accordingly and then merge, that would be easier for me :). Cheers, On Wed, Jun 1, 2011 at 12:30 AM, Ilia Alshanetsky i...@prohost.org wrote: Since we are on the topic of reviewing past RFCs for 5.4, can we take another look at the Zend Signals RFC: https://wiki.php.net/rfc/zendsignals The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? -- 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] [PATCH] Notice on array to string convertion
I like the idea of an error message when this happens, but as few other people in the thread had mentioned, I think it should be a warning (E_WARNING) because the conversion results in data loss (content of the array is replaced with Array string). On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- 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] 5.4 moving forward
Sounds fine to me. On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
This variant is not workable, because there are (in the example) in 2014 *five* branches. Merging between those, manually and automatically is going to be a major pain. I'd say we all rather want to focus our time on fixes and new features; and not spend more time doing branch merging, whatever tool we use for this. This is similar to my initial point about the proposal. We need to figure out a way to have fewer active bug-fix branches, just because it make dev live very difficult. Derick I am not sure your example is much better, since you still have 4 active branches (if I am reading the diagram correctly). I think 3 active bug fix branches, with maybe 1 security fixes only branches is the most we should have. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
Sounds reasonable. 2011/6/1 Johannes Schlüter johan...@schlueters.de: On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote: This variant is not workable, because there are (in the example) in 2014 *five* branches. Merging between those, manually and automatically is going to be a major pain. I'd say we all rather want to focus our time on fixes and new features; and not spend more time doing branch merging, whatever tool we use for this. This is similar to my initial point about the proposal. We need to figure out a way to have fewer active bug-fix branches, just because it make dev live very difficult. Derick I am not sure your example is much better, since you still have 4 active branches (if I am reading the diagram correctly). I think 3 active bug fix branches, with maybe 1 security fixes only branches is the most we should have. I mentioned this before: I like the Ubuntu model: * One development branch for the next version * One current version * One long term supported version The current version is aimed to give early access to new features, to avoid cases like traits which take years to come out while a bit more conservative users (and maybe distros) may stay on the LTS. Once a new current comes out there won't be fixes for the previous anymore. Every n-th current release will be a long term supported (LTS) release receiving only only only bug fixing and the older it gets the more critical bugs, only. What long term means can be discussed. It is open for discussion if a LTS version will directly terminate the previous LTS version or whether an LTS version will be released instead of an current version, so for one period there would be two LTS but no current branch. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
Pierre, Doing a release could be simplified through automation as you've said. However keeping synchronized patches across frequently incompatible (non-identical) code bases is much less trivial and requires quite a bit of work by anyone making the bug fixes. Having 3 branches for bug fixes makes this very non-trivial and time consuming, which is why Johannes' proposal is so appealing. 2011/6/1 Pierre Joye pierre@gmail.com: hi, 2011/6/1 Johannes Schlüter johan...@schlueters.de: On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote: This variant is not workable, because there are (in the example) in 2014 *five* branches. Merging between those, manually and automatically is going to be a major pain. I'd say we all rather want to focus our time on fixes and new features; and not spend more time doing branch merging, whatever tool we use for this. This is similar to my initial point about the proposal. We need to figure out a way to have fewer active bug-fix branches, just because it make dev live very difficult. Derick I am not sure your example is much better, since you still have 4 active branches (if I am reading the diagram correctly). I think 3 active bug fix branches, with maybe 1 security fixes only branches is the most we should have. I mentioned this before: I like the Ubuntu model: * One development branch for the next version * One current version * One long term supported version I do not like it. It does not apply to a programming language and its requirement from an end user point of view. To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a drastic improvement for ISPs, framework developers etc. The issue about having multiple or too many branches active is a non problem imo. Yes, it takes a couple of hours yet to release php, but that's something that could be automated easily (the tasks, not the whole thing) . It will also be much safer to do it given that no fancy commits can or should be applied in patch releases/stable branches. In addition we are getting more and more automated testing and that will make the release processes even smoother and safer. Unlike now where we need months to do 5.3 patches when we should have at least .7 already and .8 being in the work. 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: RFC: Short syntax for Arrays (redux)
On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates s...@seancoates.com wrote: This discussion seems to lack real-world examples… Derick wrote: I'm still -1 on it. It makes absolutely unreadable code (yes, also in JavaScript with f.e. MongoDB). Here's an actual snippet from my production code (which interfaces with ElasticSearch): http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html If you consider this readable, you're fare more literate than I will ever be (-: Using JSON syntax would only maybe make it more readable, and then only because you would probably not format it on so many lines ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
After reviewing the patch (again), I think there is no harm in support short-array syntax, similar to JSON format: $a = [1, 2, 3]; $b = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon']; So, I am changing my previous -1 to +1. On Tue, May 31, 2011 at 8:42 PM, Brian Moon br...@moonspot.net wrote: https://wiki.php.net/rfc/shortsyntaxforarrays Since this was brought again recently by Rasmus (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several people including Andi chimed in on it and Ilia seemed to reverse his thoughts as well (with caveats), I thought I would start a real thread about it. The reason the RFC stalled was stated as: This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run. So, the PHP users want it, but too many PHP core devs did not want it or did not see the use of it. From rereading the mailing list archive, most had the tone of I don't see a reason for it. I was in that camp in 2003 when it first came up. However, with the emergence of JSON and systems that use JSON as an interface, this type of syntax would be most welcome in the day to day life of a PHP developer. I would prefer (as Rasmus pointed out) not to start a long discussion about it. Primarily I would be curious if anyone on the lists (from the RFC wiki page) below would like to change your vote or if you are not listed below and would like to be counted, that would be great too. PHP SVN account holder voters = Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier Other voters Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke -- Brian. http://brian.moonspot.net -- 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] RFC: Short syntax for Arrays (redux)
Stas,
Why would you use eval() as opposed to json_decode() ?
On Tue, May 31, 2011 at 11:25 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Stas, I didn't understand your point about eval() and security. What did
you mean?
I meant if PHP has JSON syntax as native, e.g. you can say something like:
$a = {a:b};
Then the temptation would be to write something like:
// $json_string is {a:b}
$a = eval($json_string);
just as Javascript programmers sometimes do. That would have the same
security implications as it has in Javasctipt - somebody could inject
executable code there, etc. Of course, nobody forces you to do this, but the
temptation would be there.
Also, with full JSON support it is not entirely clear to me what {a: b}
would mean - is it an array or an object? In JS, it's definitely an object,
but in PHP objects are almost never used to store pure state without
behavior, because we have hashtable arrays, while JS only has vector arrays.
So here we have some unclear point (which does not happen with [] syntax,
since with [] it's obvious we're talking about arrays, just as in many other
languages).
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Rasmus,
Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?
On Tue, May 31, 2011 at 11:16 PM, Rasmus ras...@lerdorf.com wrote:
On 05/31/2011 11:52 AM, Sean Coates wrote:
I'm one of the people who've brought it up on Twitter. Today's discussion
seems to have earned some traction, which is a step in the right direction,
I believe.
I would prefer (as Rasmus pointed out) not to start a long discussion about
it. Primarily I would be curious if anyone on the lists (from the RFC wiki
page) below would like to change your vote or if you are not listed below
and would like to be counted, that would be great too.
At risk of turning this into a longer-than-necessary discussion, I believe a
new RFC is required at this point. Making [ and ] work as (T_ARRAY, '(') and
(')'), respectively is no longer good enough, for the main reason you've
pointed out: JSON is becoming ubiquitous; actual first-class JSON would be
very valuable to me.
The tricky part with going all json is the syntax, specifically the {}'s
But I think it is doable, mostly because this is not valid today:
$a = true ? { 1 : 2 };
And in json if you have {}'s you have to have a ':' inside.
I have always preferred to borrow a familiar syntax from other
languages that the average PHP user is comfortable with instead of
making up a new one.
Stas, I didn't understand your point about eval() and security. What did
you mean?
-Rasmus
--
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] RFC: Short syntax for Arrays (redux)
On Tue, May 31, 2011 at 11:59 PM, Rasmus ras...@lerdorf.com wrote:
On 05/31/2011 02:45 PM, Ilia Alshanetsky wrote:
Rasmus,
Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?
Not if we present this as native json support in PHP. Then we have to
support the {} version. Other than a couple of grumpy old-timers, I
think we are in agreement that we should add a short array syntax.
Whether we should extend that to also add a short object syntax is a
secondary question.
I guess if you present it as a native json support in PHP, it probably
would be ok from clarity standpoint. Overloading {} parser should be
doable, but a little trickier than []. The + of the current patch is
that it is very nice and simple.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Zend Signal Handling
Since we are on the topic of reviewing past RFCs for 5.4, can we take another look at the Zend Signals RFC: https://wiki.php.net/rfc/zendsignals The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
I do not believe so. On Wed, Jun 1, 2011 at 12:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? I don't know of any. Are there any issues with this change (BC, etc.)? -- 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] 5.4 again
I think an idea of an alpha right away is a good one. I feel we definitely have enough stuff in HEAD branch right now for 5.4 +/- few minor changes. It should also be a good boost to getting people on track that 5.4 is a go. On Wed, May 11, 2011 at 2:03 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, May 08, 2011 4:41 PM To: PHP Internals Subject: [PHP-DEV] 5.4 again Hi! I would like to propose the following process (of course, dates can be moved around, etc. - I consider phase lengths be more important that actual dates, but any of them can be shifted if reason arises) for 5.4: - starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear consensus support immediately. On the end of May is also phptek, so we could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for bugfixes and features in TODO list that are approved and can be done by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert another 1-month alpha period, so far it doesn't look like it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable - Release - somewhere in October or November, depending on the RCs. I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. Any exceptions that are low risk can be evaluated (an additional minor API, some additional enhancements) but let's get the good work that has been done to-date out there vs. allowing feature creep and pushing the timeline for another 1-2 years. I think we should start pushing out alpha in parallel to these discussions. Most of them sound like major features which would not make PHP 5.4 as any major feature requires plenty of time to mature (and needless to say some of them won't even be accepted). There is plenty to get excited about in PHP 5.4! Andi (sending in plaintext. Hope this gets rid of the funky newlines from prior emails) -- 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] 5.4 again
Seems like a good plan to me. Hopefully as per schedule it gets us 5.4 this year. On Sun, May 8, 2011 at 7:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I has been almost a month since we did our routine talk about 5.4, so here it goes again. The patch for the scalar hints seems to be pretty simple (see http://random-bits-of.info/no_scalar_hints.diff - no generated files included, that will be done on actual commit), so it should not hold us too much. I propose putting current code in a branch and continue without scalar typing for 5.4 - any objections to that? I would like to propose the following process (of course, dates can be moved around, etc. - I consider phase lengths be more important that actual dates, but any of them can be shifted if reason arises) for 5.4: - starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear consensus support immediately. On the end of May is also phptek, so we could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for bugfixes and features in TODO list that are approved and can be done by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert another 1-month alpha period, so far it doesn't look like it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable - Release - somewhere in October or November, depending on the RCs. I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. For proposing stuff for 5.4, please do it here: https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed and you think it requires discussion. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change default serialize precision from 100 to 17
+1
On Mon, Feb 7, 2011 at 8:26 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
The default serialize precision is currently [1] set at 100. A little code
inspection shows precision, in this case, takes the usual meaning of number
of significant digits.
Given that the implicit precision of a (normal) IEEE 754 double precision
number is slightly less than 16 digits [2], this is a serious overkill. Put
another way, while the mantissa is composed of 52 bits plus 1 implicit bit,
100 decimal digits can carry up to 100*log2(10) =~ 332 bits of information,
around 6 times more.
Given this, I propose changing the default precision to 17 (while the
precision is slightly less than 16, a 17th digit is necessary because the
first decimal digit carries little information when it is low).
From my tests, this makes serialization and unserialization of doubles
around 3 times faster (counting the function calls to serialize/unserialize,
plus a loop variable increment and stop condition check). It also makes the
serialization data.
Crucially, from my tests, the condition that the variable stays the same
before and after serialization+unserialization still holds. The test
include, for little endian machines, verifies this.
If no one objects, I'll change the default precision to 17.
//run with php -d serialize_precision=17
$numbers = array(
, //0
2d431cebe2362a3f, //.0002
2e431cebe2362a3f, //.0002 + 10^-Accuracy[.0002]*1.01
1000, //2^-1022. (minimum normal double)
01001000, //2^-1022. + 10^-Accuracy[2^-1022.]*1.01
ef7f, //2^1024. (maximum normal double)
feffef7f, //2^1024. - 10^-Accuracy[2^1024.]
0100, //minumum subnormal double
0200, //2nd minumum subnormal double
f000, //maximum subnormal double
fefff000, //2nd maximum subnormal double
0f7f, //+inf
0fff, //-inf
);
foreach ($numbers as $ns) {
$num = unpack(d, pack(H*, $ns)); $num = reset($num);
echo number: , sprintf(%.17e, $num), ... ;
$num2 = unserialize(serialize($num));
$repr = unpack(H*, pack(d, $num2)); $repr = reset($repr);
if ($repr == $ns)
echo OK\n;
else
echo mismatch\n\twas: $ns\n\tbecame: $repr\n;
}
[1]: http://lxr.php.net/opengrok/xref/PHP_TRUNK/main/main.c#451
[2]: http://en.wikipedia.org/wiki/Double_precision_floating-point_format
--
Gustavo Lopes
--
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
[PHP-DEV] PHP 5.2.16 Released!
The PHP development team would like to announce the immediate availability of PHP 5.2.16. This release marks the end of support for PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3. This release focuses on addressing a regression in open_basedir implementation introduced in 5.2.15 in addition to fixing a crash inside PDO::pgsql on data retrieval when the server is down. All users who have upgraded to 5.2.15 and are utilizing open_basedir are strongly encouraged to upgrade to 5.2.16 or 5.3.4. For a full list of changes in PHP 5.2.16, see the ChangeLog on http://php.net/ChangeLog-5.php#5.2.16. For source downloads please visit our downloads page on http://php.net/downloads.php, Windows binaries can be found on http://windows.php.net/download/. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating global + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov p...@hristov.com wrote: Hi guys, the topic says most of it. What do you think about deprecating the global keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and $_POST read-only as they should be used only to read-only anyway. I do not believe that making these read-only is going to yield any performance benefits and the chances of this breaking many scripts is quite large. -1 Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.15 Released!
The PHP development team would like to announce the immediate availability of PHP 5.2.15. This release marks the end of support for PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3. This release focuses on improving the security and stability of the PHP 5.2.x branch with a small number, of predominatly security fixes. Security Enhancements and Fixes in PHP 5.2.15: Fixed extract() to do not overwrite $GLOBALS and $this when using EXTR_OVERWRITE. Fixed crash in zip extract method (possible CWE-170). Fixed a possible double free in imap extension. Fixed possible flaw in open_basedir (CVE-2010-3436). Fixed NULL pointer dereference in ZipArchive::getArchiveComment. (CVE-2010-3709). Fixed bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data). Key enhancements in PHP 5.2.15 include: Fixed bug #47643 (array_diff() takes over 3000 times longer than php 5.2.4). Fixed bug #44248 (RFC2616 transgression while HTTPS request through proxy with SoapClient object). For a full list of changes in PHP 5.2.15, see the ChangeLog on http://php.net/ChangeLog-5.php#5.2.15. For source downloads please visit our downloads page on http://php.net/downloads.php, Windows binaries can be found on http://windows.php.net/download/. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.15RC2 5.3.4RC2 Released for Testing
The second release candidates of 5.2.15 and 5.3.4 were just released for testing and can be downloaded here: http://downloads.php.net/ilia/php-5.2.15RC2.tar.bz2 (md5sum: 423e70e49f8defd63c6a08d824357f36) http://downloads.php.net/johannes/php-5.3.4RC2.tar.bz2 (md5sum: 36f7854304f9ecaa28d56f0eb163) The windows binaries will be available shortly at: http://windows.php.net/qa/ Since the first release candidate, we have not seen a large number of changes and and there are no show-stopper bugs for either version. At this point we both feel that the next logical step is the final release, which we would like to schedule a week from now. Given that this is the case, we would like to ask all developers to refrain making commits to the 5.3 and 5.2 branches, unless these constitue critical bug fixes, in which case please let Johannes and myself know about these fixes ahead of time. This way we can avoid last minute regressions, especially so for the 5.2.15 release, which is the final one in that series. Ilia Alshanetsky Johannes Schlüter PHP 5.2 Release Master PHP 5.3 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting Binary Notation for Integers
-1 I don't think this is necessary. On Wed, Nov 10, 2010 at 4:31 PM, Jonah H. Harris jonah.har...@gmail.com wrote: Hey all, I was recently working on some code which made use of bit arrays and I came across feature request 50648: Format for binary numbers. While it's just more syntactic sugar (0b1011010 vs 2010/0x7da/03732), it doesn't seem like too bad of an idea and it is also supported by a few other languages. If there's any interest, I'll clean up the patch and resubmit. Thoughts? -- Jonah H. Harris Blog: http://www.oracle-internals.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
As long as a modifier (public|private|protected) is still required, +1.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to prevent conflicts, I therefore propose the
following RFC incl. patch to allow writing
class Foo {
public bar() {
echo Hello World;
}
}
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
johannes
--
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] [RFC] new foo()-bar()
+1
Seems like a handy change and the patch is quite manageable.
On Fri, Nov 26, 2010 at 2:36 PM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its properties
on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Looking through trunk I think we are in pretty good shape. I don't think cherry-picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. -Rasmus I Second that. The 5.4 will be backwards compatible release to the 5.3 code as far as PHP applications are concerned. The only items that would be broken are deprecated features we may choose to remove like register_globals,magic_quotes_gpc,etc... Having this release out, to let people realize the performance benefits from core + apc bundling it offers would be supremely helpful to all users of PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
I think there is much to gain by improving the serialization speed in PHP. It is used everywhere from caches like memcache, to sessions or manual data input into DB. I would say that there are very few non-trivial apps that would not benefit from a more compact and faster serializer. In our specific work-use-case switching to igbinary improved the speed of the overall page generation by 2-3%. On Thu, Nov 25, 2010 at 12:47 PM, Andi Gutmans a...@zend.com wrote: Hi, Completely different topic :) I've been looking a bit into performance around json encoding, hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled and often transmitted over the wire. I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
Just read over the BSON spec, looks fairly interesting, the only bit that appears to be missing for PHP purposes is object support. We would need to introduce custom type on top of standard BSON. However from compactness and consistency standpoint it looks fairly appealing. On Thu, Nov 25, 2010 at 2:51 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris jonah.har...@gmail.com wrote: On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote: For the record here, igbinary is a very good example of such optimization: http://opensource.dynamoid.com/ igbinary is a nice extension indeed. However, for those of us who have environments which include multiple programming languages, custom serializations become a PITA. As such, we generally go with something more portable such as Avro or straight JSON. Awhile back, I had done some work rewriting the JSON serialization functions to use the fast (and BSD licensed) yajl JSON parser (https://github.com/lloyd/yajl). Initial benchmarks showed a 4-7% performance improvement in serialization/deserialization. Good point indeed. That makes me think about bson (http://bsonspec.org/), which is used by mongodb for example. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
I don't think the version # makes that much of a difference, but rather what is in it. That said, people have made a good point that jumping to something like 7, would allow us to skip the baggage associated with PHP6, which seems like a fairly compelling argument to me. On Thu, Nov 25, 2010 at 6:01 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski z...@zend.com wrote: I think that skipping to a major version is a good idea. It is appealing but not a good idea. I think it is better to get 5.4 with the features we like in it and then consider a major version. There are quite a few things that we could add or changethat would justify a major version (without opening one of our pandora's boxes right now :). As of versioning scheme, yes, a clear and documented one is the way. Anything we can add to the RFC to clarify this would be welcome. Maybe start a new thread, it is getting hard to follow each topic. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
I too must second Mike's comments about pecl_http not being quite ready for bundling. The extension provides some useful functionality, no doubt (I use it ;-)). But I don't think there is a good case for bundling it. On Tue, Nov 23, 2010 at 7:40 AM, Michael Wallner m...@php.net wrote: On 11/23/2010 10:57 AM, Derick Rethans wrote: On Mon, 22 Nov 2010, Felipe Pena wrote: - pecl/http was planned to be bundled. What's the status? I'm all for it; but again, it's just copying it over to trunk before we branch. ... - copy over APC/pecl_http - branch on thursday - alpha next week - build a list of things that needs doing in 5.4 to get it ready (with possible options to get rid of apc/pecl_http if they are not up to date enough) Huh? I'm quite surprised to read that pecl/http is planned to be bundled with trunk, while--sure--my grand master plan included this option, there's only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt you all are talking about that version? It still needs some serious amount of work, development has stalled again due to my job's demands. Cheers, Mike -- 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] [RFC] Release Process
I think support 5 or even 3 parallel versions will be highly impractical and extra-ordinarily challenging. I think we need a plan that limits us to 2 versions and perhaps a 3rd one for critical security fixes only. 2010/11/23 Johannes Schlüter johan...@schlueters.de: Hi, On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote: With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Thanks for preparing this. I have one change proposal: With the proposed model it might, as you have illustrated, happen that there are 5 versions being maintained. As I mentioned multiple times on this list, on irc and other places I like a Ubuntu-like model with two kinds of release which I, for the purpose of this discussion, call early access (EA) and long term supported (LTS) version. At any given time only one EA may exist. When a new LTS version is being released the previous LTS version enters security-only mode to give users a transition period. Between every LTS version there are two EA versions. 2011 2012 2013 2014 2015 2016 2017 | | | | | | | | | | | | | LTS1 +---D | | | | EA1 | | D | | | | | | | | EA2 | | | | D | | | | | | LTS2 | | | | | | ---D EA3 | | | | | | | | D EA4 | | | | | | | | | | D The benefit is that developers and users who require a specific feature get it early while distributors/hosters/software vendors/... have a safe bet. johannes -- 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] Magic quotes in trunk
+1 for removing it.
On Wed, Nov 17, 2010 at 11:08 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Greetings
I wanted to raise this topic before we go Alpha with trunk, regarding
our beloved magic_quotes feature. There seems to be mixed opinions
regarding it so I thought I would take it up for discussion.
We have advised people not to use magic_quotes, register_globals and
the like for years, and they were marked as deprecated in 5.3.0+ if
activated through their php.ini directives. Yet magic_quotes still is
set to On in 5.3.0. I think its worth we either remove the feature
or disable it in trunk as its a security related feature. Lets have a
look at what each of those options means:
Removing magic_quotes):
Means we will remove the feature entirely in the source, we will throw
an E_CORE_ERROR if activated so people who have it enabled are forced
to disable it and make their applications work without magic_quotes.
This creates a minor issue for the hosts that simply disable it and
have their customers applications run without them which can create a
security risk for them, although it should be fairly limited. The
functions to check for magic_quotes_runtime should however stay for BC
to avoid applications that run on multiple versions of PHP from doing:
if(function_exists('...') ...)
Disabling them):
This will help to disable the spread of magic_quotes even more, and it
can safely be removed in the next major version of PHP.
My personal vote here goes towards removing them entirely.
What are your inputs on this matter?
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
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] Re: break/continue $var
+1 to removing it. I think now that we have goto, this functionality does not make much sense. On Fri, Nov 19, 2010 at 9:06 AM, Dmitry Stogov dmi...@zend.com wrote: without $var it would be possible to compile break/continue into ZEND_FREE/ZEND_SWITCH_FREE and ZEND_JMP. I also thought it would allow to remove op_array-brk_cont_array completely, but it's also used for exception handling. :( Thanks. Dmitry. Derick Rethans wrote: On Thu, 18 Nov 2010, Dmitry Stogov wrote: Previously we decided to remove break/continue $var syntax. I even implemented it in PHP6 brunch, however it wasn't backported into trunk. Could I do it? Is there a really good reason to remove it? regards, Derick -- 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
[PHP-DEV] PHP 5.2.15 and 5.3.4
It has been a while since the last releases in the stable branches of PHP and it is time to get the process going once again. This e-mail is a 2 week notice prior to the RC1 for both versions, the goal is to have the final releases completed by mid-December. As far as PHP 5.2 is concerned 5.2.15 is the last release before EOL that was announced this summer, the goal of this release is to finalize the various key and security fixes that were made since the last release. When it comes to 5.3.4, this is just a regularly scheduled bug-fix release. Ilia Alshanetsky Johannes Schlüter 5.2 5.3 Release Masters -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4: Adding APC
+1 to adding APC to trunk, it does compile fine (at least at the moment). On Mon, Nov 1, 2010 at 3:34 PM, Derick Rethans der...@php.net wrote: Hi! I understand that the general idea is to bundle APC with a future version of PHP. Right now, APC doesn't really compile for trunk because of internal changes. However, for PHP 5.3 it's getting into a pretty good shape. In order to add APC, what does still need to be done? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- 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] PHP 5.4: Rewriting of the parser into Lemon
We should probably stick with the bison parser for now, at least until the lemon matches the speed of the existing solution. On Mon, Nov 1, 2010 at 3:41 PM, Etienne Kneuss col...@php.net wrote: On Nov 01 15:33:59, Derick Rethans wrote: Hi! Work has been done on rewriting the PHP parser to Lemon in a specific branch: http://svn.php.net/viewvc/php/php-src/branches/LEMON/ Right now, the Lemon parser is not actually faster than the current bison parser, so I would suggest not to put this in PHP 5.4 until it performs at least as well as the current parser. Are there any possibilities for optimisation so far? I'd make the guess that it is slower due to the rule decomposition that we had to do to match bison's mid-rules syntax. We could surely optimize the decomposition but it would require a lot of rewrite in zend_compile.c, which is quite tricky to do. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- 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] [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants
Stas, Having E_FORTY_TWO would be super-useful ;-) On Tue, Aug 24, 2010 at 1:47 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Rhetorical question: Why do we need constants when the values never change? :) You seriously don't know why one needs constants or don't see a difference between constant E_WARNING equal to 8 and constant E_NONE meaning nothing and equal to 0? How about having constants ONE, TWO, THREE, FOUR? Just in case, won't hurt anybody, right? :) -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
I think that weak type-hinting defeats the whole purpose of the feature and I would rather not have it than have a non-obvious implementation. -1 On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote: At 01:47 11/08/2010, Stas Malyshev wrote: Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. I agree completely too. We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. The response to Johannes's blog also don't leave much room for speculation regarding what the community at large thinks. Facts: - When we introduced type hints, one of the 'conditions' were that we'll never, ever have type hints for scalars - for many different reasons - the strongest of which it simply doesn't fit PHP's theme. - We managed to come up with an alternative solution, in the form of auto-converting type hints for scalars, which does in fact fit PHP's theme perfectly. - I suggested we actually take the opportunity to slightly modify PHP's conversion rules in esoteric cases, where our historical decision is probably not the right one (e.g., silently converting abc into 0 in case of integer context - instead emit a new E_TYPE warning that would be off by default). My view in terms of preferences: #1 - Auto-converting type hints + minor changes to PHP's conversion rules #2 - Auto-converting type hints #3 - Doing nothing #inf - Introducing strict typing into PHP (current trunk status) As Stas said - there's clearly anything but consensus around strict typing, so our 'default' in case we can't reach agreement is #3 - the status quo. As everyone told me when this feature was committed to trunk - it doesn't mean anything, it's just trunk. Let's stand behind that statement and revert it. Strict typing should go away before any 'official' package comes out of php.net. Zeev -- 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] back to 5.4 alpha
+1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. On Wed, Aug 11, 2010 at 2:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
Pierre, With all due respect, there are plenty of things already in trunk to make it a worth while effort to start planning the 5.4 release. Just because you disagree, an opinion you are entitled to (like everyone else), does not mean it is a no go, last I checked no one had veto powers on the future release process. Johannes had already outlined a number of major features/changes in 5.4 branch that are IMHO are definitely enough to start thinking about a new version. Waiting until we got every feature, idea considered will take an indefinite amount of time and unlikely to result in a release. Additionally, a really BIG 5.4 with tons of features will take that much longer to make stable that something with a more manageable changeset. 5.4 is not the *last* PHP release, there will defiantly be others and those version can encompass features that didn't make it into 5.4. The strict type / type hinting discussion aside there definitely appears to be a consensus among the core devs that 5.4 release process should start. On Wed, Aug 11, 2010 at 6:21 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Aug 12, 2010 at 12:14 AM, Stas Malyshev smalys...@sugarcrm.com wrote: It'd be alpha, you have enough time. Is it really the new way to do things in php.net? Totally ignore other developers, discuss things privately, act like the last of the last and drop a mail to officially announce a new release/big change? And then we feel forced to act? I cannot talk for the other, but for me it is a no-go, period. I'm totally against an alpha at this stage. Not before we have clarified all we need to get a clean release. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Sounds like a reasonable name change. PHP never really had type-hinting since even array or Object type hints would throw out any value that didn't precisely match the requested type by the method/function declaration. On Tue, Aug 10, 2010 at 8:53 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Might be the time to rename what we currently call type hinting then. Because what we currently have is strict typing as well. Maybe. The term hint was inexact from the start, as hint means (Collins English Dictionary): 1. a suggestion or implication given in an indirect or subtle manner he dropped a hint 2. a helpful piece of advice or practical suggestion 3. a small amount; trace That's clearly not what is going on - there's nothing subtle or indirect there and there's not a suggestion - it's a strict and unequivocal definition of type expected for the function call. But with its use in 5.3 it didn't matter since it was clear what we are talking about and there was no possibility of confusion. Right now what we have is a classic strict typing, albeit not required for all places but f(int $f) in PHP would be the same as f(int i) in C, so calling them differently would only lead to confusion. Maybe we should have called it parameter typing or something like that from the start. It didn't seem important back then because everybody agreed what it means. Obviously it is no longer the case. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
Sascha, Does this mean @group authorizes use of NoPHP as a name for a derivative PHP version (gotta ask according to the license) ? ;-) On Tue, Aug 10, 2010 at 7:04 PM, Sascha Schumann sas...@schumann.net wrote: They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. Because it won't be. Fully agreed. I'd suggest NoPHP. AntiPHP might also work. - Sascha -- 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] PDO DBLIB Release Candidate?
PHP 5.2 branch is really for bug fixes only, so new functionality should be introduced into it. On Fri, Jul 2, 2010 at 10:11 AM, Stanley Sufficool ssuffic...@gmail.com wrote: Can I get an affirmation if the pdo dblib code will be accepted in 5.2 and 5.3 branches? -- 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] PDO_DBLIB Tests
Go ahead, if you have karma, more tests are always welcome. On Sun, Jun 27, 2010 at 8:17 PM, Stanley Sufficool ssuffic...@gmail.com wrote: I have several tests to submit for ext/pdo_dblib. I have karma to submit patches for ext/pdo_dblib, do I need a blessing to submit ext/pdo_dblib/tests tests to trunk? -- 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] Re: APC in trunk
I believe it is a *nix specific patch. On Tue, Jun 22, 2010 at 6:49 PM, Kalle Sommer Nielsen ka...@php.net wrote: 2010/6/22 Ilia Alshanetsky i...@prohost.org: We may also want to include the signals patch as part of the commit, as that both enhances speed and makes critical sections more safe, which is pretty important for opcode caches such as PHP. Whats the status of the zend signal handling RFC/patch, did it need Windows support or any other things? If so then I dont see a reason not to include it as it is now, as it will be improved anyway as we are getting closer to a release. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On windows it is even easier, just don't load the dll file, most extensions other then PCRE (?) are compiled as modules anyway... APC would be no different, and I would go as far as saying that on Win32 Wincache is probably a better choice. On Mon, Jun 21, 2010 at 2:15 AM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: The test was done on Windows... I never said it was IIS only, it is however win32 only. Sorry - Most people using it will no have bought win64 yet was the point and the test was done on win32 as far as I can tell. Anyway Pierre keeps saying that 64 bit is slower anyway ;) All extensions can be disabled by the user compiling the code... On Linux that is fine, but on Windows? We keep having this debate on what is compiled into windows builds and what is optional and that is the point here. Although the increase in third party sites providing more flexible windows builds is probably the way ahead. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- 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] APC in trunk
I for one think it is a really good idea, there is no compelling reason not to include APC, I would even go as far as say we should enable it by default. +1 On Sat, Jun 19, 2010 at 9:23 AM, Kalle Sommer Nielsen ka...@php.net wrote: Greetings As the process for trunk grows, I think we should consider which extensions we will move in and out of the core, this thread however is solely about moving APC into the core. As original proposed and agreed on the PDM in Paris, was to include APC in PHP6, and not turn it on by default. I think it will benefit both us and the community if we move APC into the core (trunk, 5.4). APC is one of the most popular extensions at PECL and many core devs also work on APC. Currently the only issue I see by putting APC into the core is the CS, as APC uses spaces instead of tabs. Another thing we might want to look at is whether we should support 5.2, or simply upgrade APC's version and break backwards compatibility so we don't have a layer of checks for macros that wasn't available in previous version, perhaps only require 5.3+ within the APC code, this however is not really a question of including APC in the core, but rather a per extension discussion ;-) What are your views on including APC in the core, or reasons not to? -- regards, Kalle Sommer Nielsen ka...@php.net -- 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] APC in trunk
Sure, but that's win32 only Ilia Alshanetsky CIO/CSO Centah Inc. On 2010-06-20, at 16:54, Derick Rethans der...@php.net wrote: On Sun, 20 Jun 2010, Rasmus Lerdorf wrote: On 6/20/10 1:21 PM, Lester Caine wrote: ( Foregot to change address again :( ) Ilia Alshanetsky wrote: What are your views on including APC in the core, or reasons not to? Dictatorship? Optional module which have well used alternatives should not be proced on by default! Probably more people use alternatives and have for years? pecl has been around for years. Nobody else has submitted an opcode cache to pecl. We certainly would not have rejected any such submission, and we still won't. Actually, there is another one: wincache. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- 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] APC in trunk
Including into core of PHP has no impact on other opcode caches, if they do a better job then APC, people can definitely (and should) use them. The main purpose of including APC would be to raise the level of awareness PHP users to the fact opcode caches exist and should be used in virtually all instances where PHP is used. Most people do not use opcode, I know it from asking that question at just about every conference. As if you do a google query searching for phpinfo() and try to find those with any cache, you'll see that there are FAR fewer of those then those without any caching being enabled. Just because APC package exists on most linux and BSD distros does not mean people know what it is, you have lots of extensions that are available as packages... How is adding an extension forcing anyone to use, dba extension has been in core in ages, and only people who choose to use it do... in core does not mean that you must use it. On Sun, Jun 20, 2010 at 8:15 PM, jvlad d...@yandex.ru wrote: Ilia Alshanetsky i...@prohost.org wrote in message news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org... Several reasons: 1) APC is well maintained, by the same people who work on PHP. 2) The license does not preclude it's inclusion into the base version. 3) most people don't use any opcode cashes, which is not ideal when it comes to PHP. 4) apc inclusion does not prevent alternatives from existing... Ilia Alshanetsky CIO/CSO Centah Inc. Ilia, -the fact that APC is well maintained is not a strong argument because the other php opcode caches are well-maintained too. Well, better or worse, that's the question. Do you by any chance have any numbers to compare that would prove your argument? -the license is compatible? Well, let's move into php core everything that has a compatible license! So it is not an agurment either. (the opposite would be a strong arument because nothing with incompatible license could be added) -most people do not use caches? To me it's not exactly correct. Did you hear of XAMPP or WAMPP packages for Windows? Did you check the modules they distribute? How many opcode caches do they deliver? At least three AFAIK. That's Windows. About BSD - did you try to compile php from ports on BSD* alike systems? Didn't you notice APC among the options? As of Linux, APC is a module officially included with all major distributions. What would change for the end-user if you move APC into trunk? From these perspectives -- very little to nothing. -p.4 reminds me Microsoft's policy. The next step would be to create a trick in the API that will prevent the others from working, but APC :) It's my understanding grin that people do not use opcode caches not because they don't really use it, but because you are not aware of it :) People who are aware of opcode caches do really use them, not necessarily the state of art and mainentance APC. They mostly use eaccelerator and xcache, successors of Dmitry Stogov's turck mmcache. Who are not aware of opcode caches won't use them anyway until you FORCE them to use it. But you're not FORCING, right? If you move APC into php trunk, nothing will really change: only name of the module would lose its *pecl* part in the name and size of sources will increase and... Now a bit more serious moment: Since APC modifies behaviour of php core and it comes side-by-side with php core (from the trunk!), it's stability can't be left over. The release manager won't be able to release any further version of PHP without knowing for sure that APC is still compatible with the other changes and it works, and php works with cached opcodes, so the testers will have to run all tests at least twice, and do this under php SAPI that works with APC using shared memory, which is not the case if command-line php is used AFAIK. From these perspectives, the benefits are not sensible, while negative impact is obvious. If you want people to be more aware of APC and use it more frequently, why not to add visiblity to APC, why not to write articles, show benefits in PHP conferences, etc. In other words, why not to go by a usual way? just my 2c -jv PS while some people are fighting for core of their projects to be as small as possible, php people are going by their own way: removing mysql extension that most people are using, and replacing it with APC that a very few would like to use... That's pity and funny. -- 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] APC in trunk
Stas, Even if the extension is compiled by default, we can (and probably should) leave apc.enabled at Off, recognizing some the things you are mentioning. On Sun, Jun 20, 2010 at 10:44 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Can you elaborate? What average user-facing features are non-obvious? We should document them if nothing else. This recently caught my attention: http://pecl.php.net/bugs/bug.php?id=16745 As I understood from this bug, APC changes how PHP works (since it works without APC but not with it) and it is not considered a problem in APC. Which means enabling APC by default is a BC break, and there's already a proof that it breaks real-life code (even if particular code had been changed to work with it, the fact that APC can break otherwise working code stays). Now probably most of the experienced users wouldn't mind fixing the code a bit, but for enabling by default it should be 100% BC. apc.file_update_protection could have some unexpected results too. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
The point is that it would be there for people to use, with as little effort as possible, which would be changing 1 byte inside the INI file. The issues APC is having with certain code is not specific to APC, and does happen with other open source caches. Perhaps we need to examine the validity of that code, or simply not cache the code that's affected. On Sun, Jun 20, 2010 at 11:19 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Even if the extension is compiled by default, we can (and probably should) leave apc.enabled at Off, recognizing some the things you are mentioning. I'm not sure I see the point of compiling it if it's disabled. Anyway, most of the distributions probably would make it .so just as it happens now for tons of other modules and would enable it in .ini. And building it from source you almost never rely on defaults anyway if you know what you want (which is the reason why you didn't use the binary one, I guess). So, summarily, I don't think we should enable it by default, as for compiling it by default, I don't think it matters too much since I don't believe defaults matter too much there. -- 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] APC in trunk
Stas, If there is a better alternative to APC we can bundle with PHP, I am definitely open to exploring that idea. However the alternatives I am familiar either are closed source or have licences incompatible with PHP, and that's without getting into the better argument. On Sun, Jun 20, 2010 at 11:31 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The point is that it would be there for people to use, with as little effort as possible, which would be changing 1 byte inside the INI file. The issues APC is having with certain code is not specific to APC, and does happen with other open source caches. Perhaps we need to We don't discuss putting other OSS (or non-OSS for that matter :) caches in any PHP build, enabled by default, do we? That's the point. And really, enabling extension - either in source build or in binary build - is not that hard. If they are able to write PHP, they should be able to remove ; before extension= or write --enable-apc. examine the validity of that code, or simply not cache the code that's affected. I'd rather not make such kludges, especially if we talk about main PHP source. It's not a good road to take. -- 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
[PHP-DEV] PHP 5.2.14RC1 5.3.3RC1 Released for Testing
The first release candidates of 5.2.14 and 5.3.3 were just released for testing and can be downloaded here: http://downloads.php.net/ilia/php-5.2.14RC1.tar.bz2 (md5sum: c269b5b5dfd571df0af4e1cabb5e9b8d) http://downloads.php.net/johannes/php-5.3.3RC1.tar.bz2 (md5sum: 50d6e7d4e0c354ccfc8a53d2eae003a9) The windows binaries are available at: http://windows.php.net/qa/ This is a beginning of the release cycle for the both releases with the goal of having a 2nd RC two weeks from now, and hopefully a final release sometime in July. Majority of the changes for both versions are of the bug fix variety. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. Ilia Alshanetsky PHP 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Pierre, If they are using PDO there are no issue, but when it comes to the extension the Sqlite3 interface is more similar to PDO in naming conventions and offers only OO interface. The SQLite2 offers both OO and procedural interface and follows its own naming convention. I don't think we should be added boat-load of wrappers for SQLite3 extension... On Tue, Jun 15, 2010 at 2:18 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, On Tue, Jun 15, 2010 at 1:41 PM, Ilia Alshanetsky i...@prohost.org wrote: After speaking to a few developers in DPC, I think it makes sense for us to drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. No objection here. However I would like to have the set of basic methods (not version specific, exec, open, etc.) to remain the same across versions so the migration could be as simple as using the new name of the sqlite class. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DEV] Remove sqlite2 from trunk
Why not just have a PHP based wrapper that would extend SQLite3 class as SQLite2 equivalent... On Wed, Jun 16, 2010 at 7:17 AM, Pierre Joye pierre@gmail.com wrote: On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky i...@prohost.org wrote: Pierre, If they are using PDO there are no issue, but when it comes to the extension the Sqlite3 interface is more similar to PDO in naming conventions and offers only OO interface. The SQLite2 offers both OO and procedural interface and follows its own naming convention. I don't think we should be added boat-load of wrappers for SQLite3 extension... That's why I explicitly mentioned 'basic' methods (exec, query and similar), the python bindings do it for example. It makes obviously no sense to do it for many advanced features. SQlite3 APIs allow that easily (cleaner naming). 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
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
Pierre, That is not your decision, since when do you decide what goes into PDO, that's a decision between the extension maintainer and the release master and since you are neither... On Mon, Jun 14, 2010 at 12:06 PM, Pierre Joye pierre@gmail.com wrote: On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, So you basically say that the worries and wishes raised here are simply irrelevant and at the end of the day you decide what PDO can or cannot be? I'm very disappointed by these two commits. I don't think it is the way we should develop PDO and it is clear that I'm not the only one to think that. As it is trunk, I won't battle too much to revert it but be sure that is not something I will let in for any of the upcoming releases as it is clearly bad design. I did not see that you even committed that to 5.3. That's definitively a no go. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/pdo/pdo_dbh.c branches/PHP_5_3/ext/pdo/php_pdo_driver.h branches/PHP_5_3/ext/pdo_pgsql/pdo_pgsql.c branches/PHP_
I'll adjust the code to simply use in_txn flag for the moment to avoid the structure change. 2010/6/14 Johannes Schlüter johan...@schlueters.de On Thu, 2010-06-10 at 12:11 +, Ilia Alshanetsky wrote: Modified: php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h === --- php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h 2010-06-10 11:45:51 UTC (rev 300350) +++ php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h 2010-06-10 12:11:19 UTC (rev 300351) @@ -310,6 +310,7 @@ pdo_dbh_check_liveness_func check_liveness; pdo_dbh_get_driver_methods_func get_driver_methods; pdo_dbh_request_shutdownpersistent_shutdown; + pdo_dbh_txn_funcin_transaction; }; /* }}} */ Here you are changing a structure which is allocated and initialized in a driver and then read from the PDO core. PDO core will therefore read invalid memory when a driver compiled against 5.3.2 is used in 5.3.3 while we usually guarantee binary compatibility in bug fix releases. This for instance affects distributors or MSFT's sqlsrv driver. johannes
[PHP-DEV] Remove sqlite2 from trunk
After speaking to a few developers in DPC, I think it makes sense for us to drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. Ilia
Re: [PHP-DEV] Remove sqlite2 from trunk
Just to clarify, removal does not mean deletion, it would simply become a PECL extension people who need it can still use. On Tue, Jun 15, 2010 at 9:30 AM, Adam Harvey ahar...@php.net wrote: On 15 June 2010 19:41, Ilia Alshanetsky i...@prohost.org wrote: After speaking to a few developers in DPC, I think it makes sense for us to drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. Funnily enough, we had a short discussion about this on IRC last week; I was meaning to write an RFC before getting swamped at work. My feeling (and I'm speaking just for myself here) is that we can't really get rid of ext/sqlite in the short to medium term: people have gotten too used to having it available and bundled in a default PHP installation. Obviously, though, we can't really keep bundling an unmaintained library, either, and we should start nudging people gently towards sqlite3. What I'd prefer: – Deprecate ext/sqlite in trunk, at least by having sqlite_open() generate an E_DEPRECATED warning. – Unbundle libsqlite2 in the next major version after what's currently in trunk and disable the extension by default, but still allow compilation against an external libsqlite2 if the user really wants to. – Move ext/sqlite to PECL at some point thereafter. PDO would be handled similarly. If someone has some real world numbers on the use of ext/sqlite, that might be handy. From where I sit, though, it does seem to have become a bit of a standard, so I'd rather not pull the rug out from under people that suddenly — particularly given it's not even deprecated at the moment. Adam
Re: [PHP-DEV] Remove sqlite2 from trunk
There is way too much code that uses ext/mysql and ext/mysql does not depend on a legacy library, I don't think we can remove it. As far as mssql, it is the one way to talk to Microsoft SQL from *nix systems, until there are good alternatives for a direct interface, I don't think we should remove it. On Tue, Jun 15, 2010 at 11:45 AM, Kalle Sommer Nielsen ka...@php.netwrote: 2010/6/15 Patrick ALLAERT patrick.alla...@gmail.com: What about doing the same with MySQL extensions ? I have the feeling that there is a benefit at removing ext/mysql with the same arguments as for sqlite 2. +1 for removing ext/mysql and ext/sqlite. While we are at it, then I think we should strongly consider removing the ext/mssql extension as well, its not maintained, there is countless bugs, and its officially not supported on Windows since 5.3, but it can however still be built and used if you do it manually. -- regards, Kalle Sommer Nielsen ka...@php.net
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
The concerns you raised about custom methods specific to database drivers were not reflective of the PDO's intent as was clarified by Wez and myself. The code that was introduced was specific to PostgreSQL, the common functionality was introduced in a way that allows each driver to implement. On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, So you basically say that the worries and wishes raised here are simply irrelevant and at the end of the day you decide what PDO can or cannot be? I'm very disappointed by these two commits. I don't think it is the way we should develop PDO and it is clear that I'm not the only one to think that. As it is trunk, I won't battle too much to revert it but be sure that is not something I will let in for any of the upcoming releases as it is clearly bad design. Cheers, -- Pierre On Thu, Jun 10, 2010 at 2:12 PM, Ilia Alshanetsky i...@prohost.org wrote: I've added the transaction code as a generic method inTransaction(), by default it'll just use in_txn internal parameter, but allows the driver to extend this (as was done in PostgreSQL) and provide a detailed status code. On Wed, May 26, 2010 at 1:11 PM, Denis Gasparin denis.gaspa...@edistar.comwrote: I attached to this mail a new version of the patch both in unified and single file format. I attached the unit tests for all the new methods too. They are three files: one for pgsqlIsInTransaction(), one for pgsqlCopyFrom* methods and one for pgsqlCopyTo* methods. I did a typo writing the documentation in my first mail. The typo is about the $fields parameter. It is actually a string (not an array) with field names separated by comma. If needed, I can write also documentation in a more suitable format for php web site. The updated documentation of the methods follows. Any feedback is appreciated. Thank you in advance, Denis pgsqlIsInTransaction() It uses the native Postgresql functions to check transaction status. It returns one of the following status codes: * PDO:GSQL_TRANSACTION_IDLE: connection in idle status * PDO:GSQL_TRANSACTION_ACTIVE: connection is executing a command * PDO:GSQL_TRANSACTION_INTRANS: connection is idle in a valid transaction block * PDO:GSQL_TRANSACTION_INERROR: connection is idle, in a failed transaction block * PDO:GSQL_TRANSACTION_UNKNOWN: connection is in a bad status pgsqlCopyFromArray($table,Array $data,$delimiter,$null, Array $fields) It uses the native Postgresql copy construct to append $data to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to * (mandatory) $data: Array of rows with data in table field order (or as specified in the $fields array). Fields must be separated by $delimiter or by postgresql standard \t) * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $data parameter. Fields are separated by comma pgsqlCopyFromFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to append $filename contents to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to. * (mandatory) $filename: file with contents to append to $table. See Postgresql documentation for the format. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $filename file. Fields are separated by comma pgsqlCopyToArray($table,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them to an array. It returns an array of rows or false in case of problems. The format of the rows into the array is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma pgsqlCopyToFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them into a file. It returns boolean. The format of the rows stored into the file is indicated in the $delimiter, $null and $fields parameters. Parameters
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
Denis, I've cleaned up the patch, fixing whitespace, a few memory leaks and optimized the copy from array code. The code for the copy to/from array/file was just committed. I am still reviewing the inTransaction code, since that is something I think can probably be generic and not database specific. On Wed, May 26, 2010 at 1:11 PM, Denis Gasparin denis.gaspa...@edistar.comwrote: I attached to this mail a new version of the patch both in unified and single file format. I attached the unit tests for all the new methods too. They are three files: one for pgsqlIsInTransaction(), one for pgsqlCopyFrom* methods and one for pgsqlCopyTo* methods. I did a typo writing the documentation in my first mail. The typo is about the $fields parameter. It is actually a string (not an array) with field names separated by comma. If needed, I can write also documentation in a more suitable format for php web site. The updated documentation of the methods follows. Any feedback is appreciated. Thank you in advance, Denis pgsqlIsInTransaction() It uses the native Postgresql functions to check transaction status. It returns one of the following status codes: * PDO:GSQL_TRANSACTION_IDLE: connection in idle status * PDO:GSQL_TRANSACTION_ACTIVE: connection is executing a command * PDO:GSQL_TRANSACTION_INTRANS: connection is idle in a valid transaction block * PDO:GSQL_TRANSACTION_INERROR: connection is idle, in a failed transaction block * PDO:GSQL_TRANSACTION_UNKNOWN: connection is in a bad status pgsqlCopyFromArray($table,Array $data,$delimiter,$null, Array $fields) It uses the native Postgresql copy construct to append $data to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to * (mandatory) $data: Array of rows with data in table field order (or as specified in the $fields array). Fields must be separated by $delimiter or by postgresql standard \t) * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $data parameter. Fields are separated by comma pgsqlCopyFromFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to append $filename contents to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to. * (mandatory) $filename: file with contents to append to $table. See Postgresql documentation for the format. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $filename file. Fields are separated by comma pgsqlCopyToArray($table,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them to an array. It returns an array of rows or false in case of problems. The format of the rows into the array is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma pgsqlCopyToFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them into a file. It returns boolean. The format of the rows stored into the file is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * (mandatory) $filename: file where to store the contents of the table * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma - Messaggio originale - Da: Ilia Alshanetsky i...@prohost.org A: Denis Gasparin denis.gaspa...@edistar.com Cc: internals@lists.php.net Inviato: Martedì, 25 maggio 2010 18:40:09 Oggetto: Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver Good reason, I'll review the patch in the next day or two. On Mon, May 24, 2010 at 5:55 PM, Denis Gasparin denis.gaspa...@edistar.com wrote: The copy to/from sql statements accept both as main parameter a filename or stdout/stdin respectively. The filename represents a file in the database
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
I've added the transaction code as a generic method inTransaction(), by default it'll just use in_txn internal parameter, but allows the driver to extend this (as was done in PostgreSQL) and provide a detailed status code. On Wed, May 26, 2010 at 1:11 PM, Denis Gasparin denis.gaspa...@edistar.comwrote: I attached to this mail a new version of the patch both in unified and single file format. I attached the unit tests for all the new methods too. They are three files: one for pgsqlIsInTransaction(), one for pgsqlCopyFrom* methods and one for pgsqlCopyTo* methods. I did a typo writing the documentation in my first mail. The typo is about the $fields parameter. It is actually a string (not an array) with field names separated by comma. If needed, I can write also documentation in a more suitable format for php web site. The updated documentation of the methods follows. Any feedback is appreciated. Thank you in advance, Denis pgsqlIsInTransaction() It uses the native Postgresql functions to check transaction status. It returns one of the following status codes: * PDO:GSQL_TRANSACTION_IDLE: connection in idle status * PDO:GSQL_TRANSACTION_ACTIVE: connection is executing a command * PDO:GSQL_TRANSACTION_INTRANS: connection is idle in a valid transaction block * PDO:GSQL_TRANSACTION_INERROR: connection is idle, in a failed transaction block * PDO:GSQL_TRANSACTION_UNKNOWN: connection is in a bad status pgsqlCopyFromArray($table,Array $data,$delimiter,$null, Array $fields) It uses the native Postgresql copy construct to append $data to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to * (mandatory) $data: Array of rows with data in table field order (or as specified in the $fields array). Fields must be separated by $delimiter or by postgresql standard \t) * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $data parameter. Fields are separated by comma pgsqlCopyFromFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to append $filename contents to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to. * (mandatory) $filename: file with contents to append to $table. See Postgresql documentation for the format. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $filename file. Fields are separated by comma pgsqlCopyToArray($table,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them to an array. It returns an array of rows or false in case of problems. The format of the rows into the array is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma pgsqlCopyToFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them into a file. It returns boolean. The format of the rows stored into the file is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * (mandatory) $filename: file where to store the contents of the table * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma - Messaggio originale - Da: Ilia Alshanetsky i...@prohost.org A: Denis Gasparin denis.gaspa...@edistar.com Cc: internals@lists.php.net Inviato: Martedì, 25 maggio 2010 18:40:09 Oggetto: Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver Good reason, I'll review the patch in the next day or two. On Mon, May 24, 2010 at 5:55 PM, Denis Gasparin denis.gaspa...@edistar.com wrote: The copy to/from sql statements accept both as main parameter a filename or stdout/stdin respectively. The filename represents a file in the database filesystem (apache/php and postgresql must reside on the same machine or share
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
Denis, I started reviewing the patch, but unfortunately things at work get a bit hectic so haven't made too much progress ;( On Thu, Jun 3, 2010 at 12:07 PM, Denis Gasparin denis.gaspa...@edistar.comwrote: Hi. Did you have the time to review the patches? Any problem with them? Thank you in advance, Denis - Messaggio originale - Da: Denis Gasparin denis.gaspa...@edistar.com A: Ilia Alshanetsky i...@prohost.org, Matteo Beccati p...@beccati.com Cc: internals@lists.php.net, pdo p...@lists.php.net Inviato: Mercoledì, 26 maggio 2010 13:11:17 Oggetto: Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver I attached to this mail a new version of the patch both in unified and single file format. I attached the unit tests for all the new methods too. They are three files: one for pgsqlIsInTransaction(), one for pgsqlCopyFrom* methods and one for pgsqlCopyTo* methods. I did a typo writing the documentation in my first mail. The typo is about the $fields parameter. It is actually a string (not an array) with field names separated by comma. If needed, I can write also documentation in a more suitable format for php web site. The updated documentation of the methods follows. Any feedback is appreciated. Thank you in advance, Denis pgsqlIsInTransaction() It uses the native Postgresql functions to check transaction status. It returns one of the following status codes: * PDO:GSQL_TRANSACTION_IDLE: connection in idle status * PDO:GSQL_TRANSACTION_ACTIVE: connection is executing a command * PDO:GSQL_TRANSACTION_INTRANS: connection is idle in a valid transaction block * PDO:GSQL_TRANSACTION_INERROR: connection is idle, in a failed transaction block * PDO:GSQL_TRANSACTION_UNKNOWN: connection is in a bad status pgsqlCopyFromArray($table,Array $data,$delimiter,$null, Array $fields) It uses the native Postgresql copy construct to append $data to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to * (mandatory) $data: Array of rows with data in table field order (or as specified in the $fields array). Fields must be separated by $delimiter or by postgresql standard \t) * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $data parameter. Fields are separated by comma pgsqlCopyFromFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to append $filename contents to $table. It returns boolean. Parameters: * (mandatory) $table: table to append data to. * (mandatory) $filename: file with contents to append to $table. See Postgresql documentation for the format. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields that are specified in $filename file. Fields are separated by comma pgsqlCopyToArray($table,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them to an array. It returns an array of rows or false in case of problems. The format of the rows into the array is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma pgsqlCopyToFile($table,$filename,$delimiter,$null,$fields) It uses the native Postgresql copy construct to retrieve $table contents and store them into a file. It returns boolean. The format of the rows stored into the file is indicated in the $delimiter, $null and $fields parameters. Parameters: * (mandatory) $table: table to retrieve data from. * (mandatory) $filename: file where to store the contents of the table * $delimiter: alternative delimiter to use in place of the standard postgres delimiter (\t) * $null: alternative string to use as null value. Default is \N * $fields: string with table fields to include in the row of the array. Fields are separated by comma - Messaggio originale - Da: Ilia Alshanetsky i...@prohost.org A: Denis Gasparin denis.gaspa...@edistar.com Cc: internals@lists.php.net Inviato: Martedì, 25 maggio 2010 18:40:09 Oggetto: Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver Good reason, I'll review the patch in the next day or two. On Mon, May 24, 2010 at 5:55 PM, Denis Gasparin denis.gaspa...@edistar.com wrote: The copy to/from sql statements accept
Re: [PHP-DEV] Type hinting
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a function that expects a boolean, but
instead gets an int/string/float, which in nearly all cases will result in
TRUE. Which is not the desired outcome.
On Thu, May 27, 2010 at 1:42 AM, Zeev Suraski z...@zend.com wrote:
At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any argument that what we're proposing to add to the
language can already be done using existing functionality. That's true
whether we're talking about strict type checking, auto-converting type
hinting, or pretty much any other idea we might come up with.
There are several reasons we still want to add this feature - reducing the
burden of validating input, making it clearer to the user what the function
expects (from the API), and in the future - it might allow for certain
optimizations.
When we come to evaluate which solution we should pick, we should go for
the solution that is the most consistent with the rest of the language and
that gives us the most bang for the buck. Auto-converting type hinting
falls in that category - it's the most consistent with the rest of the
language, and it's the most useful behavior in the vast majority of cases -
it stands a chance to become widely used. For every case where you'd
explicitly care about the zval.type (such as when you need to differentiate
between false and zero), you'd have dozens of cases where you won't. Adding
language level support for those rare cases simply doesn't make sense. The
marginal gain is minimal. The added complexity and confusion is very high.
I'm strictly against having two solutions. It's the worst outcome we could
reach IMHO - it means we're unable to decide which is better, so we support
both (kind of like a hi-tech version of http://bit.ly/9I8dHw). I think
it's the one solution that's worse than implementing strict typing only - it
does mean that I would actually support having strict typing only over
having both. Still, I think having auto-converting type hints is by far the
best solution.
Can anybody share with us *common* cases where strict typing would be
necessary, and the proposed auto-converting type hints won't do?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Brian, What we are talking about here is an **optional** feature for user-land function that allow the author to implement really cheap input-validation to facilitate ensuring that the correct input is supplied. Additionally it also allows for better language interrogation for auto-generation of things like SOAP WSDL and alike. On Wed, May 26, 2010 at 6:02 PM, Brian Moon br...@moonspot.net wrote: I like the idea of type hinting a lot. (See: http://marc.info/?l=zend-engine2m=102421231114377w=2) I suggested it in 2001 when ZE2 was being designed. Somehow my idea was bastardized into only classes and arrays. Guess it was the mad OOP craze of the time. Anyhow, I would like to use it. And, as much as I appreciate Derick and Ilia's work in getting a change in, I likely won't use it. Mainly because the web is a bunch of strings. Casting data from MySQL every time I want to use it does not interest me at all. Its a number in string form, treat it like one. If you use filter, you still have to worry with casting. There is no way to always get an int back from filter regardless of the input given. Really, I am confused what the argument is about. We already decided how this should work years ago. It should work just like the code below. Having user land functions work different than built in functions is the most confusing thing you can do. Unless of course someone plans on fixing all the internal functions too. ?php error_reporting(E_ALL); $int = 1.25454; $var = substr($int, 0, 4); var_dump($var); $var = round($var, 1); var_dump($var); $arr = array(); $var = substr($arr, 0, 1); var_dump($var); $text = test; $var = round($text, 1); var_dump($var); ? $ php test.php string(4) 1.25 float(1.3) Warning: substr() expects parameter 1 to be string, array given in /Users/brianm/test.php on line 17 NULL float(0) Brian. brianlm...@php.net http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Because auto-conversion is magic and like any magic causes in-consistent
behaviour and what I like to call WTF factor, which means the developer is
not quite certain what is going on. With strict type hints the behaviour is
consistent every-time and there is no ambiguity of function.
On Thu, May 27, 2010 at 7:03 AM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Why not do the check and let auto converting for int = float, int =
string, string = int, string = float when it doesn't loose any
precision.
2010/5/27 Ilia Alshanetsky i...@prohost.org:
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting
in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a function that expects a boolean,
but
instead gets an int/string/float, which in nearly all cases will result
in
TRUE. Which is not the desired outcome.
On Thu, May 27, 2010 at 1:42 AM, Zeev Suraski z...@zend.com wrote:
At 00:28 27/05/2010, Davey Shafik wrote:
You could just as easily say to do:
function foo($bar) {
$bar = (int) $bar;
}
as:
function foo($bar) {
if (!is_int($bar)) {
// error
}
}
Why bother with either if that's the case?
I don't think there's any argument that what we're proposing to add to
the
language can already be done using existing functionality. That's true
whether we're talking about strict type checking, auto-converting type
hinting, or pretty much any other idea we might come up with.
There are several reasons we still want to add this feature - reducing
the
burden of validating input, making it clearer to the user what the
function
expects (from the API), and in the future - it might allow for certain
optimizations.
When we come to evaluate which solution we should pick, we should go for
the solution that is the most consistent with the rest of the language
and
that gives us the most bang for the buck. Auto-converting type hinting
falls in that category - it's the most consistent with the rest of the
language, and it's the most useful behavior in the vast majority of
cases -
it stands a chance to become widely used. For every case where you'd
explicitly care about the zval.type (such as when you need to
differentiate
between false and zero), you'd have dozens of cases where you won't.
Adding
language level support for those rare cases simply doesn't make sense.
The
marginal gain is minimal. The added complexity and confusion is very
high.
I'm strictly against having two solutions. It's the worst outcome we
could
reach IMHO - it means we're unable to decide which is better, so we
support
both (kind of like a hi-tech version of http://bit.ly/9I8dHw). I think
it's the one solution that's worse than implementing strict typing only
- it
does mean that I would actually support having strict typing only over
having both. Still, I think having auto-converting type hints is by far
the
best solution.
Can anybody share with us *common* cases where strict typing would be
necessary, and the proposed auto-converting type hints won't do?
Zeev
--
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
