Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fix PDO_DBLIB bugs - FreeTDS dependency
2013/7/3 Remi Collet r...@fedoraproject.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 03/07/2013 19:17, Ralf Lang a écrit : Remi P.S sorry to have not detect this earlier (but I don't build RC for all possible targets...) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In I could set up an obs project for rhel, fedora and a service to build on each master commit etc... I just don't have enough insight to see what it means when it doesn't build ;) It's not a problem for Fedora, as all maintained version have freetds-0.91. It's not a problem for RHEL as php-mssql not provided (and EPEL also have freetds-0.91). Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHUXlkACgkQYUppBSnxahhWuwCgkH+mFuqpzFnrm97IGLmzsKP2 R3sAoLTZFzUfpEYIHoCnh+MfSmSFBWuJ =iyUp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I've pushed a build fix. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who's incharge of github pull requests?
Hi, I saw some patches from you (mentioned in the blog post) has been pushed to git. About the FTP patch, as it requires further testing and an environment for such, and we do not have an active maintainer currently for the extension. It tend to have a delay until anyone with free time (most of we are volunteers), and cares about testing the patch for such extension, to get it applied. Thanks for contributing! 2013/6/16 Lior Kaplan lio...@zend.com: Hi, It seems the list of pull requests on github is getting bigger, who's inchange to review it? https://github.com/php/php-src/pulls I must say that my experience so far in trying to push patches through the bug system or pull request is quite deprsing (comparing to other open source projects): https://liorkaplan.wordpress.com/2013/06/05/getting-patches-into-php/ Kaplan -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who's incharge of github pull requests?
2013/6/26 Lior Kaplan lio...@zend.com: Hi Felipe, Indeed I saw more responsiveness for the pull requests (mine and others), thanks. The question was about the process of reviewing these requests. 1. Do we have someone in charge (making sure they pass some minimum requirements) or this is done sporadically ? There are some core devs looking and triaging pull requests, but nobody is officially in charge to. Everyone with the needed karma can to do it. 2. If we do it sporadically, how do we make sure things aren't lost or get stuck (causing us to lose good patches). Yes, most of us are volunteers (both the developers and the patch senders) and this reflects on time issues. With that said, both sides have interest of seeing more patches sent and accepted. As I have experience with this on other projects, I'm trying to help improve the status here. Of course, I'm willing to personally help here, so I'm not just asking you guys to handle this yourselves. Kaplan Cool, so ask for a git account and join us! http://www.php.net/git-php.php On Wed, Jun 26, 2013 at 5:28 PM, Felipe Pena felipe...@gmail.com wrote: Hi, I saw some patches from you (mentioned in the blog post) has been pushed to git. About the FTP patch, as it requires further testing and an environment for such, and we do not have an active maintainer currently for the extension. It tend to have a delay until anyone with free time (most of we are volunteers), and cares about testing the patch for such extension, to get it applied. Thanks for contributing! 2013/6/16 Lior Kaplan lio...@zend.com: Hi, It seems the list of pull requests on github is getting bigger, who's inchange to review it? https://github.com/php/php-src/pulls I must say that my experience so far in trying to push patches through the bug system or pull request is quite deprsing (comparing to other open source projects): https://liorkaplan.wordpress.com/2013/06/05/getting-patches-into-php/ Kaplan -- Regards, Felipe Pena -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
Hi guys, Cannot the patch be backported to 5.4? Because actually 5.4 allows build with Bison 2.6.1, but it doesn't work for ZTS build though. 2013/3/26 Pierre Joye pierre@gmail.com: On Mar 26, 2013 12:59 AM, Christopher Jones christopher.jo...@oracle.com wrote: OK. I also tested bison 2.7. After locally patching Zend/acinclude.m4 to allow 2.7, then the PHP 5.5 testsuite has only five fails, all in gd. Which? Should be max 2 (merge issue). -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About to end 5.3
Yeah, good job on managing it! And good job everyone who has worked on this remarkable version! 2013/6/19 David Soria Parra d...@php.net: On 2013-06-19, Johannes Schlüter johan...@php.net wrote: Good bye 5.3, you were a great step for PHP! Looking forward to a bright and open future! Thank you for taking care of this branch for so long. Keep the good job up. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and beta1 archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than the one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow (...)-foo() expressions not only for `new`
Hi, Yeah. It's not a simple patch. In the past, we had a lot of problems after introducing foo()[$i] syntax, because some edge cases were not taken in account. Thanks. Dmitry. From what I remember, the same problem that I spotted by foo()[$i] is the one that we already had with foo()-prop. So it actually was a bug fix. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Non-pointer params, zend_parse_parameters, and the ! modifier
2013/2/2 Gustavo Lopes glo...@nebm.ist.utl.pt: On Sat, 02 Feb 2013 14:36:00 +0100, Sara Golemon poll...@php.net wrote: Gustavo's diff for scalars adds '!' support (this was ignored previously) by letting the NULL get cast to the type (e.g. false/0/0.0) and using a second zend_bool parameter to indicate if NULL was passed or not: long num = 42; zend_bool num_was_null; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, l!, num, num_was_null) == FAILURE) return; Now if the func is called with NULL as the argument, num will still be overwritten to 0, but we'll get the flag indicating that NULL got passed in, and we're forced to reset it to the default value (assuming that was our intent). [...] Thoughts? You raise a good point. From my part, feel free to modify it so the passed long is not changed. Yeah, makes sense. +1 -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Poor date() performance (v 5.4.9) [PATCH]
Hi,
2012/12/1 Paul Taulborg njag...@gmail.com
I am migrating from 4.4.9 to some new servers I built out, and wrote a
benchmark suite that is testing many individual aspects of PHP so I
could see what sort of performance benefits I might see not only from
the new server, but moving off my custom forked 4.4.9 branch. Here's a
snippet of some of the comparisons: (sorry for the poor formatting) --
each test is run using 1 million loops.
4.4.9 on old machine vs 5.4.9 on new machine:
for : 0.213 sec for : 0.019 sec
while : 0.145 sec while : 0.014 sec
if else : 0.449 sec if else : 0.069 sec
switch : 0.547 sec switch : 0.087 sec
Ternary : 0.418 sec Ternary : 0.066 sec
str_replace : 1.043 sec str_replace : 0.421 sec
preg_replace: 3.627 sec preg_replace: 1.678 sec
preg_match : 1.250 sec preg_match : 0.509 sec
As you can see, the new machine is considerably faster, and there are
no major issues with wanting to switch... until I get to the date
functions I make frequent use of:
date: 1.856 sec date: 2.111 sec
strtotime : 2.963 sec strtotime : 3.133 sec
and just to test (though I don't currently use it):
strftime: 2.679 sec strftime: 1.764 sec
The former two actually are slower on the new box and newer version of
php, when everything else is 2 to 200x faster.
Relevant code to the functions: (tested with and without the $now
parameter -- which makes no perceptible difference)
date('F j, Y, g:i a', $now);
strftime('%B %e, %Y, %l:%M %P', $now);
This type of formatting is pretty common. I started digging into the
source code, and found an obvious place where there was a performance
issue:
timelib_isoweek_from_date(t-y, t-m, t-d, isoweek, isoyear);
is being called every time, even though it's only used in two rather
obscure cases, and ones that are probably very uncommon in actual
practice. So, to test, I created a is set type variable, and moved
the function call into each case, with a condition checking if it was
already populated, if not, call the function to populate isoweek and
isoyear, then resume as before. (Patch will be attached as a file)
I then recompiled and reran my benchmark and here is the result:
date: 1.763 sec
Which is a performance increase of nearly 20%.
My patch was thrown together rather quickly to just do a quick test,
so it may warrant some tweaking before being applied to any branches.
I plan to continue digging, as I feel that I should be able to
continue to improve the performance of these functions further. The
rest will be a little less obvious, is there is much more cross
functionality issues to contend with to ensure nothing is broken.
Side note- I attempted the same concept with not setting the timezone
information if those flags were not used in the switch (which they
aren't in anything I use), but it didn't appear to have any noticeable
performance increase. My next step is to start tracing through actual
execution and see if I can't find any other obvious issues. My initial
thoughts are that it may be faster to try and cache some of this (for
fcgi purposes), or even have a compile time option to allow a build to
use old 4.4.9 functionality that uses localtime_r() and actually
trusts that the server has the right information set.
Thanks in advance for looking at this with me!
As far I remember, the patch must be in a .txt extension to be sent to the
list.
Thanks.
--
Regards,
Felipe Pena
Re: [PHP-DEV] Incomprehension with preg_match and utf8
Hi guys,
2012/11/6 Philip Olson phi...@roshambo.org
On Nov 5, 2012, at 8:55 AM, Rasmus Lerdorf wrote:
On 11/05/2012 08:41 AM, Jean-Sébastien Hedde wrote:
On Mon, 05 Nov 2012 08:04:06 -0800, Rasmus Lerdorf ras...@lerdorf.com
wrote:
I think the documentation is wrong on that. In Unicode mode [[:alnum:]]
actually becomes \p{Xan} which should match Unicode chars as well, but
only if PCRE was compiled with Unicode support. So I suspect you don't
actually have a Unicode-capable PCRE build in some cases there.
-Rasmus
I will report the bug to the package maintainers (remi, debian too...).
Is there anyway for us to avoid those wrong builds ?
I don't see how.
Hi geeks,
Does anyone have a suggestion on how the documentation should be
updated? The quote is from here:
http://php.net/manual/en/regexp.reference.character-classes.php
With the quote being:
In UTF-8 mode, characters with values greater than 128 do
not match any of the POSIX character classes.
A few simple/related facts:
- PCRE_UCP exists as of PCRE 8.10
- Gustavo mentioned the related PHP change on Oct 3, 2010 (not sure
what PHP version, and googling for 87a237342 turns up empty,
and I miss SVN version numbers)
Anyway, how should this be documented?
Regards,
Philip
I added PCRE_UCP on PHP 5.3.4 as a fix for bug #52971. [1]
For documentation just say something like:
In unicode mode the unicode properties are used instead to classify
characters of some classes.
More information extracted from PCRE documentation [2]:
-8---
[:alnum:] becomes \p{Xan}
[:alpha:] becomes \p{L}
[:blank:] becomes \h
[:digit:] becomes \p{Nd}
[:lower:] becomes \p{Ll}
[:space:] becomes \p{Xps}
[:upper:] becomes \p{Lu}
[:word:] becomes \p{Xwd}
Negated versions, such as [:^alpha:] use \P instead of \p.
The other POSIX classes are unchanged, and match only
characters with code points less than 128.
-
[1] - http://svn.php.net/viewvc/?view=revisionamp;revision=303963
[2] - http://pcre.org/man.txt
--
Regards,
Felipe Pena
Re: [PHP-DEV] New String Function: str_replace_limit
Hi, 2012/7/15 Paul Dragoonis dragoo...@gmail.com: Hey, I'm proposing to add a new function str_replace_limit, this will be identical to str_replace() with one key difference, you can specify how many times you want the replace to occur. Currently this isn't possible with any functions in the /ext/standard/string.c stack, the only easy workaround is using preg_replace() which requires of course the pcre library and regex patterns. I would have added this as a 4th param to str_replace(), but it already has a 4th by-ref param to tell you how many times it done the replacement. mixed str_replace_limit ( mixed $search , mixed $replace , mixed $subject [, int $limit ] ) Thoughts? Surely a 5th param is preferred. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] boolval() again
Hi, 2012/6/6 Pierre Joye pierre@gmail.com: hi, Pull it but I would still do a RFC to clearly document it (exact behaviors), which could be then used by the doc team and to implement tests. On Wed, Jun 6, 2012 at 11:51 AM, Derick Rethans der...@php.net wrote: David Soria Parra d...@php.net wrote: Going through the 26 open pull requests (please let us work on getting that number down), I stumbled over https://github.com/php/php-src/pull/60. This was already proposed on the mailinglits, but the thread died fast without a satisfying answer on whether to add a function boolval() or not. Personally I would like to see the function in. Having a complete set of XYZval() functions is a good reason for me to add that function. The implementation is simple and straight forward and easy to maintain. Do we need an RFC for that simple pull request or can we just go ahead and pull it? Pull it. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Pull it! About the RFC, I think isn't necessary as the behavior is obvious, i.e. it behaves like a cast to bool. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] concatenation operator
Hi, 2012/6/5 Adi Mutu adi_mut...@yahoo.com: Hello, Can somebody point me to where the concatenation operator is implemented ? . operator. Thanks, See http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#133 -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.3 type hint handling
Hi, 2012/6/1 Anatoliy Belsky a...@php.net: Hi, I'm experiencing an issue adding type hints to the function prototypes. The following definition gives the unknown typehint error when invoking a function ZEND_BEGIN_ARG_INFO_EX(arg_info_trader_adosc, 0, 0, 4) ZEND_ARG_TYPE_INFO(0, high, IS_ARRAY, 0) ZEND_ARG_TYPE_INFO(0, low, IS_ARRAY, 0) ZEND_ARG_TYPE_INFO(0, close, IS_ARRAY, 0) ZEND_ARG_TYPE_INFO(0, volume, IS_ARRAY, 0) ZEND_ARG_TYPE_INFO(0, fastPeriod, IS_LONG, 1) ZEND_ARG_TYPE_INFO(0, slowPeriod, IS_LONG, 1) ZEND_END_ARG_INFO(); We do not use ZEND_ARG_TYPE_INFO() with scalar types that are not covered with the type hint supports. (i.e. string, integer, double, resource) -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Parallel run-tests
Hi Zoe, great work on this new run-tests! :D I was testing it and noticed a problem when running using the following command: $ ~/dev/php5_4/sapi/cli/php run-tests.php -z 8 -p ~/dev/php5_4/sapi/cli/php ~/dev/php5_4/ It shows the PHP messages: [...] Fatal error: Call to undefined function gzencode() in /home/felipe/dev/phpruntests/src/testcase/sections/configurationsections/rtGzipPostSection.php on line 23 [...] Notice: Undefined offset: 0 in /home/felipe/dev/phpruntests/src/testcase/rtTestDifference.php on line 91 Fatal error: Allowed memory size of 134217728 bytes exhausted at /home/felipe/dev/php5_4/Zend/zend_hash.c:330 (tried to allocate 81 bytes) in /home/felipe/dev/phpruntests/src/testcase/rtPhpTestFile.php on line 108 /home/felipe/dev/php5_4/Zend/zend_hash.c(551) : ht=0x7f96e6356a50 is inconsistent [...] Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/var_unserializer.re:290 (tried to allocate 32 bytes) in /home/felipe/dev/phpruntests/src/taskScheduler/rtTaskSchedulerFile.php on line 183 2012/5/17 zoe slattery aparac...@gmail.com: Hi Over the past couple of weeks I have updated the parallel run-tests (fixed a couple of minor bugs in the PHP code and the build.xml), it's now almost at the point where I could go ahead and implement the last pieces. Here is a summary and a few questions: 1. In rebasing the code the the dev't stream I found a number of tests with non-standard sections. My code checks test case structure and objects to anything non-standard, the current run-tests.php mainly ignores this kind of thing. I fixed up about 15 of these tests (see #62022) already - I'll fix the rest if there are no objections - I will open another bug report first. 2. If there is agreement to use this code it would make sense to replace the existing run-tests code with it, or rather, it would make no sense to try and maintain both versions. The new code is OO PHP, it's in http://git.php.net/repository/phpruntests.git, is there any problem with it staying there long term and maybe copying a run-tests.phar into the PHP source directory? I have no idea what the right answer is, suggestions welcome. 3. I ran a couple of small tests on my dual core Mac yesterday. For a standard set of tests, the parallel code ran in 207 seconds, sequential in 293 seconds and the standard run-tests.php took 298 seconds. This is an improvement but I suspect we could still do better by looking at the scheduling algorithm. At the moment it's very simple, we just assemble a list of directories with tests in and hand them out to processors till everything is done. Being able to handle tests that must be run in sequence (mysql, mysqli) will mean making some changes to this. So, perhaps we give an explicit list to p1 and let the scheduler distribute the rest of the tests? Or maybe we should have a 'process map' for all tests for extensions that are build by default? Again, suggestions welcome. 4. REDIRECTTEST still needs to be implemented, I understand how it works and this isn't (afaict) a major issue. 5. Testing. I'm able to do basic testing on Mac OSX and Linux. I really need access to an 8 way Linux system, or someone who has access and would be interested in looking at performance? Any volunteers? This is probably the most interesting part of the project :-) 6. Windows. I'm not in a position to do anything much with Windows except some very basic checks to make sure that the sequential version runs. The parallel code won't work because we used pcntl(), however I know that Stefan and George were keen to design the code so that a Windows solution could be implemented if anyone thought of one. If anyone wants to pick up this aspect I'd be happy to get them started. Zoe -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trouble with zend_language_parser.y
Hi, 2012/4/26 Clint Priest cpri...@zerocue.com: I'm having some trouble setting up the re2c to allow the isset/unset. Here are the definitions, I've added the two T_ISSET statements: accessors: accessor_function accessor_function accessor_function accessor_function | accessor_function accessor_function accessor_function | accessor_function accessor_function | accessor_function | /* Empty */ ; This rule is weird too, do you want a limited number of accessor? -- Regards, Felipe Pena
Re: [PHP-DEV] Fixing string offsets of strings.
Hi, 2011/12/4 Alan Knowles a...@akbkhome.com: This is ready for review now. https://bugs.php.net/patch-display.php?bug=60362patch=fix_disabling_bad_string_offsetsrevision=1323002696 This resolves the worst behavior changes introduced by the dereferencing of strings fix. https://bugs.php.net/bug.php?id=60362 All tests (in Zend/tests) pass (after they have been modified to suit the change) Please review / comment... Regards Alan On Sunday, December 04, 2011 12:08 AM, Alan Knowles wrote: I've had a look at making string offsets of strings a bit saner. At present with the fix for array dereferencing : ?search=hello and a test like isset($_GET['search']['name']) results in true, which is has potential security problems and is very confusing for any programmer finding and working out why something like that may be failing. To solve this quite a few people agreed that not allowing non-numeric string offsets on strings would be the smart way to go, the change is going to break BC, so the idea is to at least not break it too badly... This patch is a start. https://bugs.php.net/patch-display.php?bug_id=60362patch=first_effort_to_fix_thisrevision=latest It's been quite a while since I hacked on the engine, so the patch only works reasonably well.. (see the FIXME on the tests at the bottom of the patch.) The patch changes the following: * $s = string; $s['offset'] -- produces a warning (and returns an empty string) * $s = string; $s['1'] -- works as before.. * $s = string; $s[true] $s[false] $s[0.1] -- give a notice (cast it to an int if you want to get rid of the notice) - however work as before. * changes the warning on invalid indexes to say Uninitialized or invalid rather than just Uninitialized * fixes most of the related tests I would appreciate if someone with better engine knowledge would have a look and work out what the BAD usage should return. In theory.. the fetch_dim behavior should be return a empty string if an invalid offset is used, or uninitialized zval if ISSET is calling it Regards Alan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Take a look at Zend/tests/offset_assign.phpt, there is a path hardcoded. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: getters/setters syntax Implementation
Hi,
2011/12/4 Clint M Priest cpri...@zerocue.com:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the object and the system looks for those
functions and calls them at the appropriate time.
Example:
class z {
public $Hours {
public get { return $this-_Hours; }
protected set { $this-_Hours = $value; }
}
}
Defines:
$o-__getHours();
$o-__setHours($value);
Standard __get()/__set() functionality checks for the more specifically
defined function name and calls them. I thought this would make the most
sense since it would allow us to leverage the existing inheritance
functionality. This comes out with respect to interfaces and traits in that
only errors had to be changed (for clarity) on interfaces and no changes to
traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function
body myself within zend_do_end_accessor_declaration(). One point of
contention here is that internally it defines a __$Hours property which would
be accessible from various points. I believe the standard C# get/set does
not allow any access to the underlying data storage. In order to accomplish
that there would need to be some non-standard storage or a super-private
level or something. I did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in
some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
hi Clint!
Thanks for your work so far!
On Sun, Dec 4, 2011 at 1:33 AM, Clint M Priest cpri...@zerocue.com wrote:
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the
voting phase. There is no need to hurry as the next release where this patch
could go in is next year.
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
I've fixed the zend_compile.c and zend_object_handlers.c to build with
--enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage
instead of TSRMLS_CC)
Other thing I have noticed that you have not followed our coding
standards about brackets and comments (we don't use the C++ style
one). And about the comments looks as the patch isn't finished or you
just forgot the remove them?
http://dpaste.com/665851/plain/
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: getters/setters syntax Implementation
2011/12/4 Felipe Pena felipe...@gmail.com:
Hi,
2011/12/4 Clint M Priest cpri...@zerocue.com:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the object and the system looks for those
functions and calls them at the appropriate time.
Example:
class z {
public $Hours {
public get { return $this-_Hours; }
protected set { $this-_Hours = $value; }
}
}
Defines:
$o-__getHours();
$o-__setHours($value);
Standard __get()/__set() functionality checks for the more specifically
defined function name and calls them. I thought this would make the most
sense since it would allow us to leverage the existing inheritance
functionality. This comes out with respect to interfaces and traits in that
only errors had to be changed (for clarity) on interfaces and no changes to
traits were necessary to support the new functionality.
For the automatic get/set functionality, I essentially built the function
body myself within zend_do_end_accessor_declaration(). One point of
contention here is that internally it defines a __$Hours property which
would be accessible from various points. I believe the standard C# get/set
does not allow any access to the underlying data storage. In order to
accomplish that there would need to be some non-standard storage or a
super-private level or something. I did not explore that possibility as of
yet.
I did add a couple of convenience functions that may already be available in
some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
hi Clint!
Thanks for your work so far!
On Sun, Dec 4, 2011 at 1:33 AM, Clint M Priest cpri...@zerocue.com wrote:
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the
voting phase. There is no need to hurry as the next release where this patch
could go in is next year.
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
I've fixed the zend_compile.c and zend_object_handlers.c to build with
--enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage
instead of TSRMLS_CC)
Other thing I have noticed that you have not followed our coding
standards about brackets and comments (we don't use the C++ style
one). And about the comments looks as the patch isn't finished or you
just forgot the remove them?
http://dpaste.com/665851/plain/
--
Regards,
Felipe Pena
Check out also the failing tests in Zend/tests/* (including segmentation fault)
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tweaking configure --help for autoconf changes
Hi, 2011/11/29 Daniel Convissor dani...@analysisandsolutions.com: Hi Folks: There's a minor difference between the output of configure --help between PHP_5_3 and PHP_5_4. The change makes it hard to tell what the default values are for some options. The options impacted are those defined in configure.in using PHP_ARG_WITH. A simple example is --with-layout Here's the string in configure.in: Type can be either PHP or GNU [PHP] Here's the output in PHP_5_2 and PHP_5_3: Type can be either PHP or GNU [PHP] But here is the output from PHP_5_4: Type can be either PHP or GNU PHP This is an offshoot of the move from autoconf 2.13 to 2.65. I've attached a patch for 5.4 and trunk to use autoconf quadragraph[1] representations of brackets instead of the brackets themselves. Can someone please apply this? Thanks, Applied, thanks! -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
Hi, 2011/11/24 Rasmus Lerdorf ras...@lerdorf.com: On 11/24/2011 01:08 PM, Pierre Joye wrote: hi Rasmus, On Thu, Nov 24, 2011 at 9:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: I had a quick look through the Drupal code. I don't see a single place that this is done where a deeply nested array index is applied to a string. I think you are misunderstanding what has changed here. We are leading to yet another underestimated impact to userland code, for zero gain. The risk is to high, let revert that please. For all the people saying, Revert. You guys realize that also means we revert all the array dereferencing we added elsewhere, right? That includes function array dereferencing which pretty most everyone has been clamoring for for years. So just to clarify, you think we should remove function array dereferencing? Otherwise, please provide a proposal for how we separate these various derefencing mechanisms in a way that doesn't completely destroy the clean and consistent implementation we have right now. -Rasmus The function array dereferencing is unrelated to these changes (it just touched the parser), i.e. it uses the same code used to access the array directly. -- Regards, Felipe Pena -- 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
2011/11/18 Pierre Joye pierre@gmail.com: same here, and for any other places in the ob_* APIs. Functions returns false on error, cleaning something already cleaned or empty is not an erro. Same opinion here. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Freeing $1 from zend_language_parser.y
2011/11/18 Clint M Priest cpri...@zerocue.com: Is there any reason I would have to free a pointer from the language_parser if I am just storing a reference to $1 I'm doing this: CG(accessor_node) = $1; This doesn't looks right, as $1 points to the local variable in yyparse(). And in doing so it is causing a memory leak, only if I add: efree($1.u.constant.value.str.val); It's normal when not using the alloc'ed string into the op_array. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists with float keys (bug #60039)
2011/11/18 Etienne Kneuss col...@php.net: Hi, On Fri, Nov 18, 2011 at 16:41, Nikita Popov nikita@googlemail.com wrote: *push* On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov nikita@googlemail.com wrote: Hi internals! I'd like to get some attention to bug #60039 [1]. It is about the behavior of array_key_exists with unusual keys like floats, bools and resources. Currently array_key_exists throws a warning if such a key is passed. isset() on the other hand (and native array accesses in general) treat them as valid keys, with floats being converted to ints and bools and resources treated just like ints. I would like to see array_key_exists behave consistent with isset($array[$key]) / $array[$key]. The bug has a patch attached that does this. I don't think that this change has any BC impact as it only *removes* warnings. To me, it feels similar to the Array-String conversion: It is one of those implicit conversions that is almost always indicating a bug. Therefore I would rather have both throw warnings than none of them. So -1 from me for the proposed unification. Same opinion here. I do prefer not having such implict data repair. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's the correct way to report a regression?
Hi, 2011/11/10 Dirk Haun d...@haun-online.de: I've notice, back in PHP 5.4.0 beta 2, that this test was failing: Bug #48555 (ImageFTBBox() differs from previous versions for texts with new lines) [ext/gd/tests/bug48555.phpt] So I went to https://bugs.php.net/bug.php?id=48555 and left a comment. The same test still fails in 5.4.0RC1 and also for 5.3.9RC1. Now, I have no idea if this is really a critical or important issue, but apparently a test exists for it and it fails now. So how should I go about reporting it so that somebody looks into it and decides if it's worth fixing? Since I'm not the original reporter of bug #48555, I can't edit it to update the affected PHP version. Should I have opened a new bug report instead? Would that have gotten someone's attention? Please open a new bug reporting the regression, thanks. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Phar::createDefaultStub on cli-server
2011/11/10 Scott Aubrey sc...@aubrey.org.uk: Hi List, When testing out 5.4b2 , I've noticed that the default Phar stub runs the first argument to Phar::createDefaultStub when run using the cli server. Is this right? Should i file a bug? I can't understand, please file a bug explaining such behavior. Thanks. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 52389
2011/11/10 Eric Crist ecr...@claimlynx.com: Hello folks, We've run into problems related to using Postgres as a datastore for sessions, which appears to be identified in bug report 52389 (https://bugs.php.net/bug.php?id=52389). We've tried the patch attached to the ticket, and have not seen our issue resolved. What steps can we take to expedite a fix? This bug was filed on August 21, 2010 and has seen little traction. I am prepared to provide core dumps or anything else to aid in a resolution. Hi, please post the backtrace in the bug report. And which patch have you tried exactly, the pgsql-fixed.diff one? Thanks. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl sqlite
2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()-bar()
2011/11/5 Stas Malyshev smalys...@sugarcrm.com: Hi! On 11/5/11 2:04 PM, Peter Cowburn wrote: Other examples which describes the feature at http://wiki.php.net/rfc/instance-method-call Thoughts? Bump. What's the current status on this? It would be nice to this teeny little patch in for 5.4.0 if possible. I think the brackets one is fine, if all the tests are OK we can have it in. But I'd like to get it before RC, after RC I don't want to have any substantial changes. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 Committed! -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] CI for 5.4
2011/11/3 Ferenc Kovacs tyr...@gmail.com: On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira cont...@klaussilveira.comwrote: That's kind of a general setup, Stefan. Sending an email to the commiter that broke the build with details of the build process, as well sending an email to a mailing list. I'll be looking into this Jenkins issue (JENKINS-5931). Maybe having an access control based on IRC operators and voices? yeah, using voices would work, but then that would mean that it is only a read only channel for most people, which imo would be a bad move. I mean it would be really nice, if people could drop by to our qa related irc room and start talking about that pesky build failure. another solution would be to set up a custom irc bot, independently from jenkins, which could fetch the build results through the mailing list or rss and send it to the channel. of course extending the jenkins irc bot is also a possibility, the easiest way would be having a configuration option for disabling the whole control stuff, as we don't really need the interactivity there, you can use the web interface for that. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Nice work with this Jenkins stuff! The system seems pretty useful. I like the idea to have a mailing list for build result notification, as well as send mail to the build breaker. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.4 next iteration
Hi, 2011/10/18 Stas Malyshev smalys...@sugarcrm.com: Hi! Since we have next release planned on 20th, and since we have at least three unsolved issues for 5.4 yet which we expect resolution soon: - is_a question - serialization changes - date fixes I think the release on 20th should be beta2 and we can start the RC cycle once these are resolved. BTW, if anyone remembers anything else that must be resolved before RC and isn't yet, please raise the flag. Also, it'd be great if we could get some attention to the missing documentation: https://wiki.php.net/todo/undoc54 -- 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 What about https://wiki.php.net/rfc/instance-method-call? -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Ternary operator performance improvements
2011/10/17 Ilia Alshanetsky i...@prohost.org:
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
+1 from me too.
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] new foo()-bar()
Hi, 2011/10/7 Ferenc Kovacs tyr...@gmail.com: On Tue, Nov 30, 2010 at 9:57 AM, Michael Wallner m...@php.net wrote: On 11/26/2010 08:36 PM, Felipe Pena wrote: Hi all, ... Other examples which describes the feature at http://wiki.php.net/rfc/instance-method-call Thoughts? +1 Finally. it seems that it didn't made it to the trunk/5.4. is there anything holding things back? I think Dmitry mentioned checking for memleaks and such, but I didn't remember seeing anybody really against the idea. There is no memleak from what I've tested. I only haven't a way to prevent the 1 shift/reduce conflict added by the patch, which seems harmless for our grammar though. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php
2011/9/8 Alexey Shein con...@gmail.com: Hello! I've made some improvements to run-tests.php: 1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if they're not provided, i.e. assume they have value 'auto'. You can still pass your own value as usual. 2) Added option -n (use no php.ini) to the shebang line (#!/usr/bin/php -n) so it would run more reliably on some hosts. My Ubuntu setup did not have E letter in variables_order (i.e. variables_order=GPCS) so $_ENV array was empty and some tests were skipped when they could be run. 3) Some better error handling of wrong paths So now you can run run-tests.php with just $ ./run-tests.php ext instead of $ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext You can also run run-tests.php from sub-dir, it will correctly guess 'auto' as well: $ cd ext/ $ ../run-tests.php zlib Please, review this patch and, if there's no objections, I will prepare 5.4 and 5.3 versions too. -- Regards, Shein Alexey +1 I have no tried the patch, but the additions sounds good to me. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
AFAIK Pierre has some point about Windows part. 2011/9/6 Ferenc Kovacs i...@tyrael.hu: On Tue, Aug 17, 2010 at 4:22 PM, Ferenc Kovacs i...@tyrael.hu wrote: Hi. I would like to know what is the current status of the LFS support for php. http://bugs.php.net/bug.php?id=27792 http://bugs.php.net/bug.php?id=48886 As far as I can see, there are some patches floating around, but some of them doesn't work, some of them are incomplete. As far as I can see, with the latest release(5.3.3) you can't stat or filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit. Is this true? From the proposed patches, it seems that there arent that many LOC which needs to be adjusted to provide a decent LFS support. Are there any blocker objections or architectural problems, or we just lack specification or manpower to fix this issue? If this gets fixed, will this be included into the 5.3 branch, or this can only be added with the next major version? Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php bump. Tyrael bump (hoping that maybe laruence or Felipe takes a look) Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New run-tests.php feature
2011/9/1 Kalle Sommer Nielsen ka...@php.net: Hi 2011/9/1 Hannes Magnusson bj...@php.net: Create a magical run-me-first file which run-tests will execute first, and if it fails it will skip all the tests in that directory.. should be relatively easy to implement. Being able to run the tests for two directories in parallel however.. that would be awesome. I reckon Felipe had a patch for this back in the early 5.3 development days, Felipe? -- regards, Kalle Sommer Nielsen ka...@php.net Here's the patch: http://felipe.ath.cx/diff/run-tests.diff -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Bug #55311] Static methods invoke __call when called from within class
Hi, 2011/7/29 Laruence larue...@php.net: Hi: hmm, this make sense, thanks for your explaining. Actually this behavior change was introduced in 5.3.3 [1] and reverted in 5.3.4. I.e. the BC just happens for 5.3.3 version. [1] - https://bugs.php.net/bug.php?id=51176 -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
2011/7/25 Gwynne Raskind gwy...@darkrainfall.org:
On this subject, I've been looking into what produces the largest
warnings spam with a decent set of warnings turned on, and I'd like to
recommend this patch. I can't commit it myself (I don't have Zend
karma), nor would I care to without getting some opinion on it. The
patch is against 5.4, but should apply equally to trunk. No API is
changed, and no BC issues are created; it only adds a
forward-compatible optional declarator for the end of a
zend_function_entry struct. Obviously, the spammed warning in question
is missing initializer, with respect to every function entry struct
in every extension, all of which simply use the {NULL, NULL, NULL}
from ext_skel. The intention is to provide this constant to protect
against future extensions of the structure. There are some other
structures which could also benefit from such an initializer
(smart_str and zend_fcall_info[_cache] come to mind).
Index: Zend/zend_API.h
===
--- Zend/zend_API.h (revision 313656)
+++ Zend/zend_API.h (working copy)
@@ -96,6 +96,8 @@
#define ZEND_NS_FALIAS(ns, name, alias, arg_info)
ZEND_NS_FENTRY(ns,
name, ZEND_FN(alias), arg_info, 0)
#define ZEND_NS_DEP_FALIAS(ns, name, alias,
arg_info) ZEND_NS_FENTRY(ns, name, ZEND_FN(alias), arg_info,
ZEND_ACC_DEPRECATED)
+#define ZEND_FE_END { NULL, NULL, NULL, 0, 0 }
+
#define ZEND_ARG_INFO(pass_by_ref, name)
{ #name,
sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref},
#define ZEND_ARG_PASS_INFO(pass_by_ref)
{ NULL, 0, NULL, 0, 0,
0, pass_by_ref},
#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) {
#name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT,
allow_null, pass_by_ref},
Index: main/php.h
===
--- main/php.h (revision 313656)
+++ main/php.h (working copy)
@@ -359,6 +359,7 @@
#define PHP_MALIAS ZEND_MALIAS
#define PHP_ABSTRACT_ME ZEND_ABSTRACT_ME
#define PHP_ME_MAPPING ZEND_ME_MAPPING
+#define PHP_FE_END ZEND_FE_END
#define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N
#define PHP_MODULE_SHUTDOWN_N ZEND_MODULE_SHUTDOWN_N
-- Gwynne
On Sat, Jul 23, 2011 at 19:23, Rasmus Lerdorf syst...@php.net wrote:
On 07/23/2011 04:07 PM, Gwynne Raskind wrote:
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).
That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.
-Rasmus
You're right. Someone already had reported it. I'll work on adding on
all extensions.
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
2011/7/23 Nuno Lopes nlop...@php.net: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Nice! I see the mail now works too. :) Thanks Nuno++ -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT in production
2011/7/23 Pierre Joye pierre@gmail.com: hi Stas, The idea of E_STRICT when we introduced it was to help developers. So I tend to think that we should not enable it in php.ini-production. Agreed. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is gcov.php.net still useful?
2011/7/18 Stas Malyshev smalys...@sugarcrm.com: Hi! The gcov.php.net machine is about to die. Nexcess (the owner) already offered us the possibility to get a replacement. However, before accepting their offer I would like to know if someone is still using the gcov.php.net service. Is it still useful for anyone? I think test coverage, valgrind and failures report are useful, especially that we're nearing 5.4 release. The latter probably we could also get from QA reports, but others probably not - like coverage, valgrind, parameters etc. reports. BTW parameters report needs to be updated - it doesn't know about new 'p' parameter. It already was updated, but wasn't synced with svn. And I used to read the test failures and valgrind logs on gcov as well. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
2011/7/14 Rune Kaagaard rumi...@gmail.com:
Will this work:
array('foo', 'bar')('arg1', 'arg2')
?
No, and it isn't supposed to either.
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Hi, 2011/7/10 Nikita Popov nikita@googlemail.com: On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny l...@strojny.net wrote: Very good find of an inconsistency. Does the testsuite reveal something strange with that patch? I didn't test that patch, just found it in the bugtracker. cel...@php.net would be a better person to ask, as he wrote it. But just from glancing at it I could imagine that it would break token_get_all() as CG(active_class_entry) wouldn't be set appropriately (though that's just a guess). Yes, you are right. We cannot rely on CG(active_class_entry) data. I'm against this patch, because we will just add more inconsistency. Allow reserved words in method name, OK. But what about class name/namespace name etc? And in the begin of thread the topic was type name as class name, nothing to do with methods. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
2011/7/10 Lars Strojny l...@strojny.net: Hi everybody, Attached is the patch against current trunk with a testcase, tokenizer tests do not break. If nobody objects, could somebody with commit access to Zend could commit this patch? Wait, wait. Tokenizer surely is broken, it will identify a method name 'include' as T_INCLUDE. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Hi, 2011/7/10 Lars Strojny l...@strojny.net: Hi Felipe, Am 11.07.11 00:41 schrieb Felipe Pena unter felipe...@gmail.com: I'm against this patch, because we will just add more inconsistency. Allow reserved words in method name, OK. But what about class name/namespace name etc? Good argument, namespace names and class names should be treated similar. Would you object a patch doing it for class names, interface names and namespaces? To handle the class name in a method call turn out tricky. For example: include::list(); When matching 'include' we have to check if it's (ignoring whitespaces and comments) an 'include ..', 'include(...)', 'include::'. This will require massive use of lookahead, which lead to handling trailing context in the scanner, for each current reserved words. It's not so simple. Using re2c we can to match 'include' only if followed by something using the r/s syntax, but this doesn't solve all. As the one could use: include /* foobar */ ::list() - and even being quite weird, it should keep working. Complexity++ -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets broken in 5.4 on Mac OS X
Em 10 de julho de 2011 20:21, Stas Malyshev smalys...@sugarcrm.com escreveu: Hi! I was now building 5.4 on Mac with sockets enabled and got this: /Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function ‘php_if_index_to_addr4’: /Users/smalyshev/php-5.4/ext/sockets/multicast.c:426: error: ‘struct ifreq’ has no member named ‘ifr_ifindex’ /Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function ‘php_add4_to_if_index’: /Users/smalyshev/php-5.4/ext/sockets/multicast.c:506: error: ‘SIOCGIFINDEX’ undeclared (first use in this function) /Users/smalyshev/php-5.4/ext/sockets/multicast.c:506: error: (Each undeclared identifier is reported only once /Users/smalyshev/php-5.4/ext/sockets/multicast.c:506: error: for each function it appears in.) /Users/smalyshev/php-5.4/ext/sockets/multicast.c:513: error: ‘struct ifreq’ has no member named ‘ifr_ifindex’ Redoing buildconf/configure didn't help. Any ideas? There's a report about this: - https://bugs.php.net/bug.php?id=55111 -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
Hi, 2011/7/5 Adam Harvey ahar...@php.net: Developers, Romans, countrymen, I'd like to propose the addition of a -W switch to the CLI SAPI which would enable the display of errors and maximum error reporting. This brings us into line with other languages such as Perl, and allows us to evangelise to users that they should run php -W script.php as the preferred way of developing and running new, E_STRICT-compliant scripts. The RFC is at https://wiki.php.net/rfc/cli-strict, and comes with a patch, which is accessible at http://www.adamharvey.name/patches/php-cli-strict.patch.txt. If the response isn't overwhelmingly negative and we don't get caught up in discussions for the next few days, I'll look at calling for a vote in a week or so (given it's not a language-level change). Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Just to inform, the Perl's -W enable all warnings regardless of whether the script disable warnings. The Perl's -w one looks like your -W, but I know we already have used -w in PHP to output source with stripped comments and whitespaces. However I guess it's more useful to have something like Perl does with -W. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object oriented session handlers
Hi,
2011/6/2 Arpad Ray array...@gmail.com:
Hi,
A while ago I submitted a patch to allow session_set_save_handler() to
accept a class, and support the inheritance of the default session
handler's methods.
The RFC has a more detailed description and the current patch:
https://wiki.php.net/rfc/session-oo
Changes since this was last discussed:
- More sanity checking to prevent handlers being called in unexpected states
- ZTS fixes
Any thoughts?
Regards,
Arpad
I like the idea (and voted +1 on it), but I've some consideration to do:
+/* {{{ proto bool SessionHandler::open(string save_path, string session_name)
+ Wraps the old open handler */
+PHP_METHOD(SessionHandler, open)
+{
+ PS_SANITY_CHECK;
+
+ PS(mod_user_is_open) = 1;
+ RETVAL_LONG(PS(default_mod)-s_open(PS(mod_data), PS(save_path),
PS(session_name) TSRMLS_CC));
+}
[..]
+ZEND_BEGIN_ARG_INFO(arginfo_session_class_open, 0)
+ ZEND_ARG_INFO(0, save_path)
+ ZEND_ARG_INFO(0, session_name)
+ZEND_END_ARG_INFO()
This method does not take the save_path and session_name parameter, it
just use the INI entry.
This lead to following behavior:
$x = new SessionHandler
$x-open(1,2,3,4); // param is not used, and no param check at all
It's missing void param check for the close method as well.
Thank you for helping us make PHP better. :)
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compilation warning on offsetof in 5.4 and trunk
Hi, 2011/7/2 Jérôme Loyet jer...@loyet.net: Hi, in 5.4 and trunk, there is compilation warnings all pointing to STD_PHP_INI_ENTRY /home/fat/dev/php-src/trunk/sapi/fpm/fpm/fpm_main.c:1465:109: warning: cast from pointer to integer of different size /home/fat/dev/php-src/trunk/sapi/fpm/fpm/fpm_main.c:1466:85: warning: cast from pointer to integer of different size the warnings appear in sapis (cgi, fpm, ...) and extensions (standard, ...) and the problem comes from the XOffsetOf macro which is expanded to offsetof defined in Zend/zend_operators.h whit the following code added in revisions 311662 and 312264: #ifndef offsetof #define offsetof(t,f) \ ((int)(((t*)0)-f)) #endif Before this addition, XOffsetOf was expanded to ((long) (((char *) t*)((void *)0))-f))) - ((char *) ((void *)0 which is defined at the end of main/php.h. Two questions: 1- is this possible to change Zend/zend_operators.h to use the old macros ? (short term solution) I've removed this offsetof definition introduced in r311662, it seems have been added accidentaly, as the code in this revision do not use it. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Improved parser error message
2011/5/18 Gustavo Lopes glo...@nebm.ist.utl.pt:
Em Tue, 17 May 2011 17:49:53 +0100, Stas Malyshev smalys...@sugarcrm.com
escreveu:
I think we need to keep token name in the message, since it makes it
easier to understand what parser expected if you need to debug the parser
(as opposed to your code). So I think we need to have both the
human-readable name and the token name, as Andi suggested.
I think this alternative has very little value for debugging the parser.
There are no repeated labels for the tokens, so even if you don't know the
token name by heart, you can look it up in 10 seconds.
Keeping the token name will only perpetuate the confusion it has caused. I
think it ought to be dropped, but if no consensus can be reached, this would
be better than the status quo.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
So, following some suggestion I made a patch wich displays such messages:
$ sapi/cli/php -r 'class '
Current:
Parse error: syntax error, unexpected $end, expecting T_STRING
Patched:
Parse error: syntax error, unexpected end of file, expecting
'identifier' (T_STRING)
$ sapi/cli/php -r 'class abc foo'
Current:
Parse error: syntax error, unexpected T_STRING, expecting '{' in
Command line code on line 1
Patched:
Parse error: syntax error, unexpected 'foo' (T_STRING), expecting '{'
in Command line code on line 1
As can be noticed, I added the actual scanned string in the
unexpected part. This might be useful for finding really which makes
the parser error. (It was a bit tricky though :D)
Any thoughts?
https://wiki.php.net/rfc/improved-parser-error-message
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
2011/6/21 Etienne Kneuss col...@php.net: Hello, On Tue, Jun 21, 2011 at 05:17, Rasmus Lerdorf syst...@php.net wrote: On 06/20/2011 08:09 PM, Felipe Pena wrote: I'm ok with this, I just think it's ugly to repeat the token name in the definition in the .y file. :P %token T_LNUMBER 'number' (T_LNUMBER) %token T_STRING 'identifier' (T_STRING) Why 'identifier' and not 'string' or 'string-literal' there? For people using php, a string or a string literal is foo or 'foo'. T_STRING does not represent foo nor 'foo'. identifier seems to adequatly describe what it encompass. IMHO, it would even be better if the unnexpect part displayed the actual content: i.e. function 1() = Unexpected number '1' ... or function 1() = Unexpected '1'... Currently it's possible to do this, it'll only require a static variable in yytnamerr implementation. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
Hi, 2011/6/20 Robert Eisele rob...@xarg.org 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 I like this one, +1. -- Regards, Felipe Pena
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
Hi, 2011/6/20 Etienne Kneuss col...@php.net Hi, On Fri, Jun 17, 2011 at 00:08, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Below is the list of the features proposed for inclusion in 5.4, as outlined in https://wiki.php.net/todo/php54. Please read the TODO page and the RFCs linked there for details. This mail is not a vote call but rather description of things that will be put to vote soon. For each one, I'd like to see that: a. It is clear to everybody what is being proposed. If you have any doubts or see that it needs further discussion, please tell. b. We didn't miss something. If you have a proposal that has RFC in good shape, patch (or can have patch within 1 month from now) and you think has to be in 5.4 and has good chance for community support, please tell. I'd love to see the proposal from Felipe about the improved parse errors in that list. I believe that the patch was ready or almost ready? I can't find the RFC though, but maybe the RFC never existed... Best, https://wiki.php.net/rfc/improved-parser-error-message -- Regards, Felipe Pena
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
2011/6/20 Derick Rethans der...@php.net
On Mon, 20 Jun 2011, Felipe Pena wrote:
2011/6/20 Etienne Kneuss col...@php.net
I'd love to see the proposal from Felipe about the improved parse
errors in that list. I believe that the patch was ready or almost
ready? I can't find the RFC though, but maybe the RFC never existed...
https://wiki.php.net/rfc/improved-parser-error-message
I think this is good and helpful.
I've two suggestions though:
- Add the token name in parenthesis at the end of the string
- Add '' around the token strings
Examples:
Parse error: syntax error, unexpected '=' (T_SL_EQUAL) in Command line
code on line 1
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in
Command line code on line 1
Parse error: syntax error, unexpected 'quoted-string'
(T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line
code on line 1
To have the quoting message working as desired, we need to implement
the yytnamerr function (based in the default one)
e.g.:
static YYSIZE_T zend_yytnamerr(char *yyres, const char *yystr)
{
if (!yyres) {
return yystrlen(yystr);
}
if (*yystr == '') {
YYSIZE_T yyn = 0;
char const *yyp = yystr;
while (1) {
if (*++yyp != '') {
yyres[yyn++] = *yyp;
} else {
yyres[yyn] = '\0';
return yyn;
}
}
}
return yystpcpy (yyres, yystr) - yyres;
}
I'm ok with this, I just think it's ugly to repeat the token name in
the definition in the .y file. :P
%token T_LNUMBER 'number' (T_LNUMBER)
%token T_STRING 'identifier' (T_STRING)
$ sapi/cli/php -r 'function 1'
Parse error: syntax error, unexpected 'number' (T_LNUMBER), expecting
'identifier' (T_STRING) or '(' in Command line code on line 1
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
Hi,
2011/6/8 Christian Kaps christian.k...@mohiva.com
Hi,
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009
which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the
array('class',
'method') is an old known for call_user_func()-like functions.
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array('Hello','world');
var_dump($f('you'));
$f = array(new Hello, 'foo');
$f();
All such calls match with the call_user_func() behavior related to magic
methods, static non-static methods.
The array to be a valid callback should be a 2-element array, and it must
be
for the first element object/string and for the second string only. (just
like our zend_is_callable() check and opcodes related to init call)
Any thoughts?
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this-bar = array($this, 'baz');
$this-bar();
}
public function bar() {
echo 'bar';
}
public function baz() {
echo 'baz';
}
}
new Foo();
What is the output of this snippet?
Are there the same rules as for closures?
Christian
Yes, the same rules.
--
Regards,
Felipe Pena
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
2011/6/8 Christian Kaps christian.k...@mohiva.com
On Wed, 8 Jun 2011 08:57:48 -0300, Felipe Pena wrote:
Hi,
2011/6/8 Christian Kaps christian.k...@mohiva.com
Hi,
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this-bar = array($this, 'baz');
$this-bar();
}
public function bar() {
echo 'bar';
}
public function baz() {
echo 'baz';
}
}
new Foo();
What is the output of this snippet?
Are there the same rules as for closures?
Christian
Yes, the same rules.
Hi,
I think for the sake of consistency it should be possible to use the
following code.
class Bar {
public function __construct($dispatcher) {
$dispatcher-addEventListener('onUpdate', $this-onUpdate);
}
public function onUpdate() {}
}
If a property $onUpdate exists then it will be ignored. The same rules as
for Closures or for array callbacks.
Christian
It works in the same way:
class foo {
public function __construct() {
$this-bar = function () { return 1; };
// $this-bar(); // error
$x = $this-bar;
$x(); // ok
$this-bar = array($this, 'baz');
// $this-bar(); // error
$x = $this-bar;
$x(); // ok
}
public function baz() {
echo 'baz';
}
}
--
Regards,
Felipe Pena
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
Hi,
2011/6/6 Dmitry Stogov dmi...@zend.com
Hi Felipe,
I like the idea. It makes indirect method calls less expensive.
I would add a hint to specializer, to eliminate small overhead for regular
function calls.
} else if (OP1_TYPE != IS_CONST
EXPECTED(Z_TYPE_P(function_name) == IS_ARRAY)
zend_hash_num_elements(Z_ARRVAL_P(function_name)) == 2) {
Thanks. Dmitry.
Dmitry:
Oh, right. I added the check for OP2_TYPE != IS_CONST, thanks for reviewing.
Christopher Jones:
Alright, I'll write a page in the wiki for the record.
All:
Committed in 5.4 and trunk now.
Thanks for the comments, folks! :)
--
Regards,
Felipe Pena
Re: [PHP-DEV] bug #39863 in trunk/5.4
Hi, 2011/6/5 Stas Malyshev smalys...@sugarcrm.com Hi! Of course, I was just checking if it's what you guys are thinking first. Well, there was basically two ideas: 1. Add filename length to streams and check inside streams 2. Check inside argument parser Both have downsides: (1) does not capture cases when we don't use streams (such as direct stat/touch/etc functions), (2) doesn't cover the case when stream is manipulated through a string not coming directly from a function argument (e.g. include, but may be other cases with extensions). So, ideally, it'd be nice to have both - or something third that I didn't think of - but any of them is better than nothing. (1) seems to be easier and less disruptive, provided that we cover include case separately and locate all functions that deal with filenames. Ok, I've committed in 5.4 and trunk the argument parser part. Now I need to fix some tests and try to found other places needing for related checks. Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] bug #39863 in trunk/5.4
Hi, 2011/6/5 Pierre Joye pierre@gmail.com hi, Not apparently, it was not fixed in trunk. There was a discussion about using zend_arg for paths and additional function or macros to be used instead of duplicating the tests everywhere. But no consensus or agreement have been reached. Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough (beyond changing others function parse args, fixing the tests, include+require part)? $ sapi/cli/php -r 'fopen(a\0b, r);' Warning: fopen() expects parameter 1 to be valid path, string given in Command line code on line 1 Thanks. -- Regards, Felipe Pena
[PHP-DEV] $arr = array('Hello', 'world'); $arr();
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009 which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the array('class',
'method') is an old known for call_user_func()-like functions.
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array('Hello','world');
var_dump($f('you'));
$f = array(new Hello, 'foo');
$f();
All such calls match with the call_user_func() behavior related to magic
methods, static non-static methods.
The array to be a valid callback should be a 2-element array, and it must be
for the first element object/string and for the second string only. (just
like our zend_is_callable() check and opcodes related to init call)
Any thoughts?
[1] - http://bugs.php.net/bug.php?id=47160
[2] - http://felipe.ath.cx/diff/fr47160.diff
phpt: http://felipe.ath.cx/diff/fr47160.phpt
--
Regards,
Felipe Pena
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
2011/6/5 Benjamin Eberlei kont...@beberlei.de
That can lead to quite a bit of simplifications in code where you now have
to check for is_array/is_callable/instanceof Closure and such. I like it.
Exactly, and since our current $x = 'hello::world'; $x(); doesn't support
method calls, the array one can help on this just like the call_user_func()
approach with arrays.
?php
class Hello {
static public function world($x) {
echo Hello, $x\n;
}
}
function hello_world($x) {
echo Hello, $x\n;
}
$callbacks = array(
array('Hello', 'world'),
function ($x) { echo Hello, $x\n; },
'hello_world'
);
foreach ($callbacks as $k = $callback) {
if (is_callable($callback)) {
$callback($k);
}
}
Output:
Hello, 0
Hello, 1
Hello, 2
--
Regards,
Felipe Pena
Re: [PHP-DEV] RFC: Zend Signal Handling
Fixed crash in fastcgi due startup order...
SIGG() were being used before tsrm_startup().
2011/6/4 Felipe Pena felipe...@gmail.com
Fixed invalid sigaction() call passing NSIG as signal number.
- for (signo = 1; signo = NSIG; ++signo) {
+ for (signo = 1; signo NSIG; ++signo) {
Detected by Valgrind:
==4577== Warning: bad signal number 65 in sigaction()
2011/6/3 Ilia Alshanetsky i...@prohost.org
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
--
Regards,
Felipe Pena
--
Regards,
Felipe Pena
Re: [PHP-DEV] bug #39863 in trunk/5.4
2011/6/5 Stas Malyshev smalys...@sugarcrm.com Hi! Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough (beyond changing others function parse args, fixing the tests, include+require part)? $ sapi/cli/php -r 'fopen(a\0b, r);' Warning: fopen() expects parameter 1 to be valid path, string given in Command line code on line 1 This should be applied not only to fopen but to any function that does anything with filenames (and include/require/etc. also, I guess). Of course, I was just checking if it's what you guys are thinking first. -- Regards, Felipe Pena
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
Hi,
2011/6/5 Zeev Suraski z...@zend.com
-Original Message-
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array(new Hello, 'foo');
$f();
Am I the only one who doesn't understand what this one is supposed to do..?
If you are refering to the 'foo' method and the lack of arg, it's was a
typo...
The right one:
?php
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array(new Hello, 'world');
$f('devs');
--
Regards,
Felipe Pena
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
Hi, 2011/6/5 Stas Malyshev smalys...@sugarcrm.com Hi! So, I wrote a patch [2] that allow such behavior to be consistent with arrays. See some examples: Looks good. Only question I have is that we seem to have that code (calling a function based on variable) in two places instead of one, I wonder if it's necessary and if we could unify them... We have the code to initialize the call from a object variable, and string variable (function only) in this exact opcode ZEND_INIT_FCALL_BY_NAME, which now treat the array case as well, there is no other place doing such stuff. -- Regards, Felipe Pena
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
2011/6/5 Stas Malyshev smalys...@sugarcrm.com Hi! We have the code to initialize the call from a object variable, and string variable (function only) in this exact opcode ZEND_INIT_FCALL_BY_NAME, which now treat the array case as well, there is no other place doing such stuff. What about call_user_func() implementation? It must be doing pretty much the same thing. 1. We do not use zend_fcall_info stuff in the VM (which zend_is_callable works in) 2. We have to use zend_do_fcall_common_helper instead of zend_call_function() in the VM -- Regards, Felipe Pena
Re: [PHP-DEV] RFC: Zend Signal Handling
Fixed invalid sigaction() call passing NSIG as signal number.
- for (signo = 1; signo = NSIG; ++signo) {
+ for (signo = 1; signo NSIG; ++signo) {
Detected by Valgrind:
==4577== Warning: bad signal number 65 in sigaction()
2011/6/3 Ilia Alshanetsky i...@prohost.org
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
--
Regards,
Felipe Pena
Re: [PHP-DEV] RFC: Zend Signal Handling
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 -- Regards, Felipe Pena
Re: [PHP-DEV] RFC: Zend Signal Handling
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
Re: [PHP-DEV] Constructor object instance dereferentiation
Hi, 2011/5/22 Matthew Weier O'Phinney weierophin...@php.net One thing not on the RFC that I'm curious about: if the class defines __invoke(), would the following work? new MyClass()(); That would be particularly useful for implementing helper systems, which are quite often one-off use cases. No, such feature was not planned in the RFC, the patch doesn't change the grammar to allow it. -- Regards, Felipe Pena
[PHP-DEV] Re: [RFC] Improved parser error message
2011/5/16 Felipe Pena felipe...@gmail.com Hi all, As I have proposed previously in an old thread... What about we name all the tokens to have an improved parser error message? (i.e. anymore T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc) [...] Other examples and patch at: https://wiki.php.net/rfc/improved-parser-error-message Any thoughts? Thanks. So... In case of no objections, I'll commit it in trunk and 5_4 branch, Is it okay? :) -- Regards, Felipe Pena
[PHP-DEV] [RFC] Improved parser error message
Hi all,
As I have proposed previously in an old thread... What about we name all the
tokens to have an improved parser error message? (i.e. anymore
T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
Some examples:
$ sapi/cli/php -r 'function '
Patched:
Parse error: syntax error, unexpected quoted-string, expecting identifier or
'(' in Command line code on line 1
Current:
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting
T_STRING or '(' in Command line code on line 1
$ sapi/cli/php -r 'echo ::a;'
Patched:
Parse error: syntax error, unexpected :: in Command line code on line 1
Current:
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in Command line
code on line 1
Other examples and patch at:
https://wiki.php.net/rfc/improved-parser-error-message
Any thoughts?
Thanks.
--
Regards,
Felipe Pena
Re: [PHP-DEV] [RFC] Improved parser error message
Hi, 2011/5/16 Ferenc Kovacs i...@tyrael.hu +1 do you think that this could cause some kind of BC? I don't think that anybody out there parses the tokens as is, but there are crazy people. :) the other thing that I can imagine that the developers will be surprised that they are getting meaningful error messages, but I think they can live with that. :) Tyrael There is no BC. The changes doesn't affects token_*() functions for example. $ sapi/cli/php -r 'var_dump(token_name(318));' string(6) T_ECHO I added such information to the wiki page. Thanks. :) -- Regards, Felipe Pena
Re: [PHP-DEV] SVN Account Request: eyalt
Anyone, please? 2010/11/29 Patrick ALLAERT patrickalla...@php.net Can someone please approve eyal's account request with the following karma?: php/php-src/*/tests Thanks, Patrick 2010/11/22 Patrick ALLAERT patrickalla...@php.net: Eyal provided already a fair number of contributions/remarks on the php-qa ML. Regards, -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor 2010/11/21 Eyal Teutsch eya...@zend.com: mainly submitting PHPTs fixes. -- 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 -- Regards, Felipe Pena
Re: [PHP-DEV] [RFC] new foo()-bar()
Hi Dmitry, 2010/11/29 Dmitry Stogov dmi...@zend.com Hi Felipe, I'm wondered it works out of the box with so small patches :) However, both patches introduce new parser conflicts and it would be grate to avoid them. I will check if there is any way to avoid it. Also the patches need to be checked for memory leaks in case of exceptions thrown from constructor and chained function(s). Yes, I already did several tests to check this. It also probably makes sense to add array deference chaining e.g. new Foo()[] (just for language consistency). Hmm, looks good to me. :) Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] [RFC] new foo()-bar()
2010/11/29 Felipe Pena felipe...@gmail.com
It also probably makes sense to add array deference chaining e.g. new
Foo()[] (just for language consistency).
Hmm, looks good to me. :)
I've updated the patch with the bracketed version to include the array
dereferecing support:
http://felipe.ath.cx/diff/instance-method-call-3.patch
?php
class foo extends ArrayObject {
public function __construct($arr) {
parent::__construct($arr);
}
}
$arr = array(1, 2, 3);
$value = (new foo($arr))[1]; // int(2)
?
Some tests: http://felipe.ath.cx/diff/instance_direct_access_001.phpt
--
Regards,
Felipe Pena
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/28 Ross Masters r...@php.net From what I understand T_FUNCTION would be optional, rather than removed altogether, is this the case? This would allow those who want to use it the option of using it and would not break existing code. Yes, exaclty... -- Regards, Felipe Pena
Re: [PHP-DEV] [RFC] new foo()-bar()
Hi,
2010/11/26 Felipe Pena felipe...@gmail.com
2010/11/26 Johannes Schlüter johan...@schlueters.de
On Fri, 2010-11-26 at 17:36 -0200, Felipe Pena wrote:
var_dump(new foo()-bar()-x); // string(3) PHP
It has some readability issues. One might assume it is
new (foo()-bar()-x)
not
(new foo())-bar()-x
As there is a mandatory space between new and its operand and no space
in front of the object operator and we allow non-constant operands to
new.
So what is
new $bar-foo();
? If I read the patch correctly this is valid and evaluated as
(new $bar)-foo();
johannes
new foo()-bar() should be read as: (new foo())-bar().
And using variable:
new $bar-y()-x should be read as: (new ($bar-y)())-x.
?php
class foo {
public $x = 1;
}
class bar {
public $y = 'foo';
}
$bar = new bar;
var_dump(new $bar-y()-x); // 1
?
I.e. just as it is nowdays.
Well, if this feature is going to be accept, we could to decide what syntax
to use.
I have created another patch which is the bracketed version of this
presented here.
?php
class foo {
public $x = 1;
}
class bar {
public $y = 'foo';
}
$x = 'bar';
$bar = new bar;
var_dump((new bar)-y); // foo
var_dump((new $x)-y); // foo
var_dump((new $bar-y)-x); // 1
?
Thus we do not have the readability issues, as pointed by Johannes.
http://wiki.php.net/rfc/instance-method-call (updated!)
Thanks for the comments.
--
Regards,
Felipe Pena
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter johan...@schlueters.de 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 +1 -- Regards, Felipe Pena
[PHP-DEV] [RFC] new foo()-bar()
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
Re: [PHP-DEV] [RFC] new foo()-bar()
2010/11/26 Johannes Schlüter johan...@schlueters.de
On Fri, 2010-11-26 at 17:36 -0200, Felipe Pena wrote:
var_dump(new foo()-bar()-x); // string(3) PHP
It has some readability issues. One might assume it is
new (foo()-bar()-x)
not
(new foo())-bar()-x
As there is a mandatory space between new and its operand and no space
in front of the object operator and we allow non-constant operands to
new.
So what is
new $bar-foo();
? If I read the patch correctly this is valid and evaluated as
(new $bar)-foo();
johannes
new foo()-bar() should be read as: (new foo())-bar().
And using variable:
new $bar-y()-x should be read as: (new ($bar-y)())-x.
?php
class foo {
public $x = 1;
}
class bar {
public $y = 'foo';
}
$bar = new bar;
var_dump(new $bar-y()-x); // 1
?
I.e. just as it is nowdays.
--
Regards,
Felipe Pena
[PHP-DEV] [RFC] Release Process
Hi, 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] PHP releases have always been done spontaneously, in a somehow chaotic way. Individual(s) decided when a release will happen and what could or could fit in. Release managers role are unclear and the way to nominate them is not clearly defined either. The goals of this RFC aim to solve these issues while giving to us, our users and 3rd parties (distributions, contributors, etc.) more visibility and the ability to actually have a roadmap, or plan developments. This RFC aims to define: * a clear release cycle, periodic * a transparent decision process for the feature additions, via the RFCs and a transparent but anonymous vote * which changes can be done during a release lifetime (BC breaks, bugs fixes, security fixes, etc.) * a transparent way to choose release managers for a given release * a better usage of bugs.php.net to track each change, addition, bug fixes (security incl.) or other various tasks related to a release * reduce time between bugs fix releases * reduce the time to get new features in a release * suppress BC breaks in bugs fix releases * feature(s) preview release [1] http://wiki.php.net/rfc/releaseprocess -- Regards, Felipe Pena
[PHP-DEV] Hold off 5.4
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
- Traits may not be ready yet for pre-release
- see http://svn.php.net/viewvc?view=revisionrevision=298348
- APC support
- There are many changes not BC with 5.x, as we allowed them for the
development tree, before 5.4 was even a topic
- APC is not yet bundled. Having the opcode bundle can raise issues by
one or another, we should have it in from the very 1st release
- pecl/http was planned to be bundled. What's the status?
We also have no plan about what will or will not be 5.4. This looks
familiar, this is exactly how we begun 5.3 and it tooks literally
years to be released. There is also actually no agreement to begin
with 5.4 now.
5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.
Thanks.
--
Regards,
Felipe Pena
Re: [PHP-DEV] break/continue $var
2010/11/18 Dmitry Stogov dmi...@zend.com Hi, 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? +1 to removing it. -- Regards, Felipe Pena
Re: [PHP-DEV] Restructuring NEWS?
Hi, 2010/11/19 Johannes Schlüter johan...@schlueters.de On Fri, 2010-11-19 at 02:23 +0200, Jani Taskinen wrote: 19.11.2010 0:39, Johannes Schlüter kirjoitti: Hi, after the 5.3.3 release I was approached with the request to restructure the NEWS file -- for instance by grouping entries by extension -- so users can identify whether there are bug fixes relevant for them etc. Something that I did in trunk NEWS perhaps? I'd like a better formatted NEWS though. I didn't see that change but yeah something like that. Aybody volunteers to go through the 5.3 NEWS? :-) I groupped the the 5.3.4RC1 entries: http://dpaste.com/277482/plain/ Is it okay to commit? :) -- Regards, Felipe Pena
Re: [PHP-DEV] [PATCH] fix extract w.r.t GLOBALS again
Hi,
2010/11/19 Joe Orton jor...@redhat.com
The check to prevent extract() overwriting $GLOBALS got broken at some
point - here's a fix:
Index: ext/standard/array.c
===
--- ext/standard/array.c(revision 305556)
+++ ext/standard/array.c(working copy)
@@ -1389,10 +1389,10 @@
case EXTR_OVERWRITE:
/* GLOBALS protection */
- if (var_exists var_name_len ==
sizeof(GLOBALS) !strcmp(var_name, GLOBALS)) {
+ if (var_exists var_name_len ==
sizeof(GLOBALS)-1 !strcmp(var_name, GLOBALS)) {
break;
}
- if (var_exists var_name_len ==
sizeof(this) !strcmp(var_name, this) EG(scope)
EG(scope)-name_length != 0) {
+ if (var_exists var_name_len ==
sizeof(this)-1 !strcmp(var_name, this) EG(scope)
EG(scope)-name_length != 0) {
break;
}
ZVAL_STRINGL(final_name, var_name,
var_name_len, 1);
Index: ext/standard/tests/array/extract_safety.phpt
===
--- ext/standard/tests/array/extract_safety.phpt(revision 0)
+++ ext/standard/tests/array/extract_safety.phpt(revision 0)
@@ -0,0 +1,24 @@
+--TEST--
+Test extract() for overwrite of GLOBALS
+--FILE--
+?php
+$str = John;
+debug_zval_dump($GLOBALS[str]);
+
+/* Extracting Global Variables */
+$splat = array(foo = bar);
+var_dump(extract(array(GLOBALS = $splat, EXTR_OVERWRITE)));
+
+unset ($splat);
+
+debug_zval_dump($GLOBALS[str]);
+
+echo \nDone;
+?
+
+--EXPECTF--
+string(4) John refcount(2)
+int(0)
+string(4) John refcount(2)
+
+Done
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I committed your fix in the 5.2, 5.3 and trunk.
Thanks for the patch!
--
Regards,
Felipe Pena
Re: [PHP-DEV] [PATCH] fix extract w.r.t GLOBALS again
Hi Chris, 2010/11/19 Chris Stockton chrisstockto...@gmail.com On Fri, Nov 19, 2010 at 8:43 AM, Joe Orton jor...@redhat.com wrote: The check to prevent extract() overwriting $GLOBALS got broken at some point - here's a fix: I remember http://bugs.php.net/47409 for this some time ago and seeing it marked applied. After taking a peak it looks like the patch in the bug report was ignored. One more reason why I stopped contributing I guess. The fix committed to the related bug was just like your patch, except that you did the right sizeof() - 1. Then as you see, we need contributions... making patches... testing fixes... reviewing fixes... As it's said in the bugsweb... Help us make PHP better. :) -- Regards, Felipe Pena
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ UPGRADING.INTERNALS ext/standard/basic_functions.c ext/standard/basic_functions.h main/php_streams.h main/streams/memory.c main/streams/streams.c
Em 15 de novembro de 2010 14:49, Gustavo Lopes glo...@nebm.ist.utl.ptescreveu: On Mon, 15 Nov 2010 08:25:44 +0100, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2010/11/15 Gustavo André dos Santos Lopes cataphr...@php.net: cataphract Mon, 15 Nov 2010 03:05:32 + Revision: http://svn.php.net/viewvc?view=revisionrevision=305346 Log: - Added leak_variable() function. Why do we need a leak_variable() function in a regular build unlike leak() and crash() which are defined in zend_builtin_functions.c in debug mode only or did I miss something here? It's only in the debug build. In any case, it would be indeed better among leak() and crash(). The attached patch moves it there, but it will have to be someone else commiting it. Done. -- Regards, Felipe Pena
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Restructuring the QA team
Hi, 2008/11/3 Pierre Joye pierre@gmail.com hi, On Mon, Nov 3, 2008 at 9:08 AM, Ronald Chmara r...@opus1.com wrote: On Oct 31, 2008, at 5:16 AM, Sebastian Bergmann wrote: Hannes Magnusson schrieb: Speaking of QA people, how about crediting those who are actually working on QA and removing the names who haven't been around for years (I don't even recognized most of those names)? How do you recommend measuring who deserves credit? Who recommends (and how do they recommend) credit for PHP core? Who recommends (and how do they recommend) credit for PHP extensions? We have a credits file and new names are added while older/inactive developers are kept. .oO( 2 years ago... ) New people are active in the developement, and others became inactive... and we don't updated the credits list. What about an update in the credits list (especially in the QA team)? How will be decided? I guess many people deserve credits (e.g. Dmitry, Pierre, etc), and this practice doesn't happens since many years. -- Regards, Felipe Pena
Re: [PHP-DEV] BC break in 5.3.2 - 5.3.3 with parent:: and __call/__callStatic
2010/10/24 Giovanni Giacobbi giova...@giacobbi.net
Greetings,
in reference to bug #52713 i'd like to inquire you about this decision
which actually broke my codebase in different parts.
The situation is this one:
class ActiveRecord {
public function __call($method, $args) {
if ($method == getFoo) {
// implement some default behaviour for getFoo()
}
}
public function __callStatic($method, $args) {
// do some other stuff
}
}
class Bar {
// override getFoo() to add some specific behaviour
public function getFoo() {
// do the specific stuff
parent::getFoo();
}
}
Until version 5.3.2 this worked fine, starting from version 5.3.3
parent::getFoo() calls __callStatic() instead of __call().
This is a really bad BC change which i thought you decided to accept only
in minor versions change and not patch-level versions change.
Anyway, I would even be willing to do some changes to my codebase, but what
is the solution? I can't see any other way to do this with the obvious
assumptions that my design is good and that I don't know anything about the
parent class except there is a getFoo() method implemented somehow.
My wish is that you restore the 5.3.2 behaviour, which sounds very
reasonable, and maybe introduce another way when you actually want to get
rid of the context, something like static::
The change has been reverted in SVN.
Thanks.
--
Regards,
Felipe Pena
Re: [PHP-DEV] Re: Bug #47643 - array_diff slowdown
Hi, 2010/11/1 Lonny K lon...@gmail.com Can we get some opinions on this. I'm willing to make the changes, but I want to get some sort of consensus on this. Basically I believe the problem is that patch 42838 should be reverted and the documentation should be updated. Someone on IRC had disagreed with me so I want more opinions before I do anything. The slowdown on array_diff has been fixed right now. Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
2010/11/1 Richard Lynch c...@l-i-e.com On Fri, October 29, 2010 7:47 pm, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. -1 Instead of renaming the token, I prefer to associate a literal string to each token, to have a legible error message, without the T_ being shown. For example, we could use in the Bison grammar file: %token T_PAAMAYIM_NEKUDOTAYIM :: So that the error message become: $ sapi/cli/php -r '::' Parse error: syntax error, unexpected :: in Command line code on line 1 Instead of the known unexpected T_PAAMAYIM_NEKUDOTAYIM one. -- Regards, Felipe Pena
Re: [PHP-DEV] [PATCH] Delegate type hint/checks to alternative locations (Re: [PHP-DEV] back to 5.4 alpha)
Hi,
2010/10/19 Derick Rethans der...@php.net
Hi!
On Sun, 5 Sep 2010, Derick Rethans wrote:
I've spend some more time on this, and have attached a new patch that:
- Removes the strict type verification, changing it back into typehints
only.
- Keeps the current syntax so that typehints create structures in the
function entries.
- Keeps the reflection API for the syntax, so that you can query the
typehints.
- Changed the API so that the verification function can also modify the
variables.
I've just committed that patch, the implements the 3 first elements from
this list. I've also updated my little extension to behave in the same
way as it did with the previous patch:
There is a BC in the changes, I don't know if it is expected for the next
version, at least it is very strange.
?php
class int { }
function f(int $a) { }
f(new int); // no error
f('foo'); // no error
f(null); // no error
?
--
Regards,
Felipe Pena
Re: [PHP-DEV] [RFC] Return type-hint
Hi
2010/7/29 Ferenc Kovacs i...@tyrael.hu
Hi, I would love this feature.
But I have some concerns.
AFAIK you can declare classes with the name int ,scalar, etc. so
hinting anything else than class names can be ambiguous.
Or we have to set these keywords as reserved, so nobody could declare
classes with such names.
Weren't they already made reserved with the parameter type hinting patch?
As I said:
Maybe this was resolved with the last scalar type hinting patch, which
got merged to the trunk, I don't know.
Currently on trunk version, if you use the php native types as type-hint it
will check for the php type, not the user class.
Trunk:
?php
class int { }
function test(int $a) { }
test(1); // ok
test(new int); // error
Which is just like the return type-hint is working. I do prefer offer a way
to continue using the user class 'Int', as we not going to add new
keywords... My suggestion (I guess already told it in some mail...) is to
identify the native php type just when it's lowercased (case-sensitive).
(Java-style)
Patch: http://felipe.ath.cx/diff/param-typehint-native-type.diff
Example:
?php
class int { }
function test(Int $a) { } // user class 'Int'
function test2(int $a) { } // native type 'int'
test(new int); // ok
test2(1); // ok
Thanks for the feedbacks. :-)
--
Regards,
Felipe Pena
[PHP-DEV] [RFC] Return type-hint
Hi all, I've updated the patch and the RFC that proposes the return type-hint implementation (Engine + Reflection). The proposed implementation is working just like the last changes in the parameter type-hint (in trunk). i.e. working with the scalar and numeric pseudo-types. http://wiki.php.net/rfc/returntypehint Thoughts? -- Regards, Felipe Pena
Re: [PHP-DEV] [PATCH] string_offset access optimization
Hi Dmitry, 2010/7/15 Dmitry Stogov dmi...@zend.com Hi, Recently I noticed that reading of string offset is performed in two steps. At first special string_offset variant of temporary_variable is created in zend_fetch_dimension_address_read() and then the real string value is created in _get_zval_ptr_var_string_offset(). I think we can create the real string in the first place. This makes 50% speed-up on string offset reading operation and allows to eliminate some checks and conditional brunches in VM. The patch is attached (don't forget to regenerate zend_vm_execute.h to test it). However it changes behavior in one bogus case. The following code now will emit b (currently it generates a fatal error - cannot use string offset as an array). $str = abs; var_dumo($str[1][0]); I think it's not a problem at all. b makes sense because abs[1] - b and b[0] - b. I'm going to commit the patch in case of no objections. Thanks. Dmitry. The patch looks good, I did some tests, not found anything strange. Good simplyfication! :) -- Regards, Felipe Pena
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3/Zend/zend_compile
2010/6/28 Johannes Schlüter johan...@schlueters.de Hi, On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote: felipe Sat, 26 Jun 2010 22:05:13 + Revision: http://svn.php.net/viewvc?view=revisionrevision=300770 Log: - Fixed bug #51421 (Abstract __construct constructor argument list not enforced) Bug: http://bugs.php.net/51421 (Closed) Abstract __construct constructor argument list not enforced Won't this break compatibility? I'd say the change is logically correct but not sure we should break BC there during RC. Reverted. ;) -- Regards, Felipe Pena
Re: [PHP-DEV] Suggestion: echo function(var)[0];
Hi all,
2010/6/5 Felipe Pena felipe...@gmail.com
Hi!
2010/6/4 Stas Malyshev smalys...@sugarcrm.com
Hi!
function call chaining (f()() if f() returns function), and array
dereferencing (f()[0]) - (Stas)
I did patch for f()() - it's referenced at
http://wiki.php.net/rfc/fcallfcall - but not for f()[] - didn't have time
for that yet.
It should not be too hard to do, one just has to be careful with refcounts
so that the returned result could be freed properly and without hurting the
referred element.
I wrote a patch, but I cannot test all cases, so I'm not sure if is okay at
all.
What about this approach: http://felipe.ath.cx/diff/array_dereference.diff?
I've updated the patch, now it works with method call as well.
Example:
?php
class foo {
public $x = 10;
public function bar() {
$x = array();
$x[] = 3;
$x[] = array(1, 5);
$x[] = new foo;
return $x;
}
}
$foo = new foo;
var_dump($foo-bar()[2]-bar()[0]); // 3
var_dump($foo-bar()[2]-bar()[1]); // array(0 = 1, 1 = 5)
var_dump($foo-bar()[2]-bar()[1][1]); // 5
var_dump($foo-bar()[2]-bar()[2]-x); // 10
function test($arr) {
$x = $arr;
return $x;
}
$array = array(1, new foo);
var_dump(test($array)[0]); // 1
var_dump(test($array)[1]-bar()[0]); // 3
var_dump(test($array)[1]-bar()[2]); // object(foo)
http://felipe.ath.cx/diff/array_dereference.diff
Thanks.
--
Regards,
Felipe Pena
[PHP-DEV] [RFC] Array Dereferencing
Hi all, I just edited the RFC page [1] about array dereferencing as now we have a patch for such. RFC page: http://wiki.php.net/rfc/functionarraydereferencing The patch is simple, it just required to change the grammar file. I also added some tests in the patch. Any objection? Thought? Improvements? Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] [RFC] Array Dereferencing
2010/6/7 Stas Malyshev smalys...@sugarcrm.com Hi! This is great. Did you check it on debug version though? I thought for some reason you'd have to take care of freeing the value (which is returned by function) after the expression is done, but maybe I missed something. It's be also nice to see some more assignment tests (also maybe return-array-by-ref test). I checked it with debug and every case I could think of and it seems to be working just fine, so - commit it to trunk :) Yes, I always use ZTS+Debug build :P I have committed the patch and added new tests. Thanks guys for the feedback. -- Regards, Felipe Pena
