Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Fri, 2013-02-22 at 08:44 +0100, Martin Keckeis wrote: > I think there may come many critics maybe, but why not move those things > also to github? > It's used by many people. it works, it's easy! It is easily two steps back. Yay! (Tags are funny but don't help with categorization of bugs on PHP's scale, the initial comment was on improving the Voting, github has no voting at all, ...) So if you have issues with the bug tracker please log a bug ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5 alpha 5 is released
Hi Internals, PHP 5.5.0alpha5 has been tagged and released. This release contains bug fixes against alpha4, and adds new features in the mysqli and mysqlnd API, new HTTP codes and the possibility to change the temp directory using a php.ini directive. The packages can be found at: http://downloads.php.net/dsp As you know, you may read the NEWS file in the source tree for full changelog of this release. Please test PHP5.5.0alpha5 carefully, and report any bugs in the bug system. We may begin now the beta stage of 5.5.0. As you should know, we had a delay for beta due to some late coming features such as Zend Optimizer +. Please, be warned that the first beta will be the last release for you to add new features. After first beta, features will get frozen, next betas won't accept new features and should focus on consolidating the code against bugs. The first beta should be tagged on March 7th. Thank to all the contributors that mainly gave their time to make this alpha5 possible. Regards David and Julien
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Fri, Feb 22, 2013 at 8:44 AM, Martin Keckeis wrote: > 2013/2/21 Johannes Schlüter > > > On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote: > > > > > > I am specifically thinking of Bugzilla which is already used by many > > > open source projects. It has a lot more features than your current > > > bug > > > tracking system, it scales for large projects and it has a few > > > Mozilla > > > employees working full time on it. > > > > > I'm a passive user of bugzilla, not involved with any project using it > > but every time I have to report a bug on a project using it I think > > twice, why do I have to register and run away if I have to remember the > > password I used 2 years ago when reporting my last bug. > > > > bugs.php.net might not be as shiny as others but it makes reporting > > easy, fill in a captcha and you are done, no registration or such, you > > might even use a fake mail address (not that it necessarily helps to be > > unreachable for getting things resolved) > > > > And then there is a religious thing: Bugzilla is written in a legacy > > language ;-) > > > > And yes. it has some rough edges, but it get's it's job done, integrates > > with out user system, our "what's the current version"-notification > > system, ... > > > > > I think there may come many critics maybe, but why not move those things > also to github? > It's used by many people. it works, it's easy! > > Zend Framework also done the move from SVN, signing a CLA, own Bug tracking > system. to github and I think it couldn't be better now! > it would require some changes in our process and infrastructure: - currently the bugtracker supports private bugs (mostly 0day security reports) AFAIK github doesn't have that, so we would have to use another channel (like using the secur...@php.net alone), which would be worse than the current solution when the security bugs (with all of the discussion) are opened up after the fix is released - currently we don't require a registration for reporting bugs, with the github issues the reporter needs to be registered and logged into github. - currently the bugtracker authenticates the contributers using their php.net credentials, github doesn't provide a way for that, so potentially ever contributer should be registered on github and added as a collaborator to be able to assign/edit/resolve issues. (and potentially the process should be automated, so when a php.net user is approved/granted karma he/she should be added to the collaborators automatically, I suppose there is a way to do that in the github api). - currently the bugtracker supports blocking the comments for a specific bug, github doesn't have that kind of feature. - currently the bugtracker supports providing version, OS information, the github issues doesn't have any way to have custom fields, maybe the labels/tags could be (ab)used for this, and we would need to automate this so when a new version is added, the label should automatically pushed to github. - currently the bugtracker supports providing package information, that would either require us to split the php-src repo into multiple repositories (ext/*, Zend/, etc. this would be a bad idea imo) or we would need to use labels for this also(and the labels should.be automatically updated when a new package is created). - currently the bugtracker supports providing bugtype information(bug, feature request, documentation issue, security), see above. - currently the bugtracker supports closing the issues with Quick Fixes, where there is a predefined comment automatically added to the bug so we don't have to copypaste the resolution message for similar bugs (that the website/docs related fixes needs time to propagate, that fixing a bug in the head means that it will be fixed in a future release etc.), github issues doesn't have this kind of feature. These are the issues(from the top of my head) which need to be resolved if/when we wanna move the tracker to github. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On Fri, Feb 22, 2013 at 10:39 AM, Johannes Schlüter wrote: > On Fri, 2013-02-22 at 08:44 +0100, Martin Keckeis wrote: > > > I think there may come many critics maybe, but why not move those things > > also to github? > > It's used by many people. it works, it's easy! > > It is easily two steps back. Yay! (Tags are funny but don't help with > categorization of bugs on PHP's scale, the initial comment was on > improving the Voting, github has no voting at all, ...) > > So if you have issues with the bug tracker please log a bug ... > > sigh, yeap, I forgot to mention the voting what we have (reproducible and importance), github also lacks those. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: [lists.php] Re: [PHP-DEV] PHP 6 : a new API ?
> So why not avoiding this by adding it as methods of the scalar variable > instead, aka autoboxing. > This would allow the new api to be closer to what people are used to from > other languages, needs far less typing and IDE autocomplete of available > functions pr type with "->". I would also prefer autoboxing, at least for arrays and strings (unsure about numbers). Would also be cool with some resources e.g. gd library. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
Ramus, thanks for your detailed response. NFS is so common for sharing files that ... This is simply not true. I do have a fair bit of experience in this field, and I don't know of any major sites that do this and I have worked with a good chunk of the largest sites out there. Eh??? Fortune 500 enterprises and governmental departments are pretty conservative. NAS and SAN based iSCSI and FCoE based elastic block storage give great performance for server-specific file-systems, but Brendon is right: for distributed file systems, NFS and CIFS still dominate. By major I meant traffic-wise, not Fortune-500, although there are some of those on the list too. I mostly work with medium-to-large scale Internet companies. Think Yahoo, Facebook, Flickr, Digg, Etsy, WePay, Room77. These types of companies would never consider serving all their Web traffic from NFS. Yes, Yahoo had a ton of Netapp filers as well, but this was for shared data storage, they would never consider putting their application logic on them. Now I agree with you: for this sector of Internet B2C companies, their business is centred around a small number of apps that dominate their revenue streams, so of course they are free to design their infrastructure architecture to optimize the performance of these apps. I also accept that this sector was and is directly or indirectly the major funder of PHP development effort. However, my counter point is that this is no longer the only infrastructure usecase for PHP. Now mature, it has entered other sectors and Brendon and Daniel posts highlight two of them: * Enterprise use as Brendon raises. Enterprises have moved to use internet based technologies to automate internal business processes. These apps work on the company intranet, not on the internet. So when you book a car or go to your bank or order a part from a manufacturer, the assistant may well be sitting in front of a PHP app that never sees the internet but is still core to that business. Thanks partly to the flexibility of cloud resources, CIOs and CTOs are increasingly looking at open technologies such PHP to replace MS ones. Incidentally IMO, its this sort of business stream that will provide hard funding to value-add companies such as Zend. * The hosting service providers as Daniel raises. In terms of sheer numbers this is that largest community of PHP users who buy their +/- $100pa service from a hosting provider. They still care about performance. The providers care about the efficiency of their infrastructure. They (initially) using PHP because Wordpress, Mediawiki, ... are written in it. But this is also a major entry vehicle for a new generation of PHP developers to get an initial internet presence. If PHP runs 3x slower than language X, and X is just as flexible then we are putting up unnecessary barriers to their entry and turning away that new cadre. This is also something that has been like this for 10+ years and nobody has stepped up to fix it so far. It shouldn't be news to anyone that stats and opens over NFS are slow. I am not sure why it should suddenly be an urgent problem for us at this point. But like I said, we may get to it. It's not suddenly urgent but perhaps this is more a question of maybe hitting a tipping point where it might now be wise to address this issue. If the integrated opcode cache happens it becomes easier to manage the flow between the compiler, the cache and the executor and we can probably optimize some things there. +1 And as I mentioned in another thread, let's see some RFCs proposing how to fix some of these things rather than simply posting "I wish the PHP devs would do this.." type of messages. These go over really badly with most of the longtime contributors here and they even tend to have the opposite of the desired effect. As I have posted separately, I forked and then rewrote APC to address this sweet spot. OK my LPC is very a much bug-ridden alpha code that fails 10% of the PHP test suite largely due to extension interoperability issues, and I've had other things to do this last month -- including deciding whether to switch to a proper O+ delta. However, my aim was for me to use this as an evaluation test bed, not a serious production contender. However, now that I've written an opcode cache which runs Mediawiki under php-cgi (with ~ 5% of the NFS getattrs, BTW), rolling some key tweeks into the Zend compiler, execution environment and APC -- which I understand well and should be straight forward -- or O+ -- which I don't as yet. My challenge is deciding (i) do I work on PHP 5.6 / 5.7 and the corresponding beta APC version which at current rates of adoption might have begin to have an impact in the community sometime in the next 5 years, or (ii) work on a performance patch to the stable APC version which is typically installed with PHP 5.3 which these guys could apply within a few months.
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
> My challenge is deciding (i) do I work on PHP 5.6 / 5.7 and the > corresponding beta APC version which at current rates of adoption might > have begin to have an impact in the community sometime in the next 5 years, > or (ii) work on a performance patch to the stable APC version which is > typically installed with PHP 5.3 which these guys could apply within a few > months. > or contribute those patches back and integrate them into the vanilla apc? for me it seems that Rasmus opinion was that having improvements in this area would be welcome, but personally it was never a high priority for the current authors and there is a chance that it won't change, so if nobody steps up and create a patch, there is no guarantee that this will be addressed soon. > > I'll draft the RFCs if the webmaster gives me the karma to do so. > sure, just drop a mail to the php-webmaster list (as far as I can see you have yet to do that). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 22/02/13 11:20, Ferenc Kovacs wrote: My challenge is deciding (i) do I work on PHP 5.6 / 5.7 and the corresponding beta APC version which at current rates of adoption might have begin to have an impact in the community sometime in the next 5 years, or (ii) work on a performance patch to the stable APC version which is typically installed with PHP 5.3 which these guys could apply within a few months. or contribute those patches back and integrate them into the vanilla apc? Humm. I think that we are sort of saying the same thing, but at cross purposes. Of course I should offer any up patches for mainstream APC and at best these will go into 3.1.14 or 3.1.15 and may then get adopted sometime for production systems whenever -- that's only if the release of a core O+ doesn't drop APC into legacy status. However Ubuntu 12.04-LTS is a good example of a stable production stack and this uses PHP 5.3.10 and APC 3.1.7. Debian Squeeze is even further behind and it runs PHP 5.3.3 and APC 3.1.3. A performance patch could also be made available based on the last stable version of APC, say 3.1.9 -- that is before the attempts to support the new PHP 5.4 features destabilised it. With this patch, then at least individual system admins would have the option to download a stable version from PECL + patch it to use with their production stacks within the next 3-6 months. Regards Terry
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On Fri, Feb 22, 2013 at 1:52 PM, Terry Ellison wrote: > On 22/02/13 11:20, Ferenc Kovacs wrote: > > > My challenge is deciding (i) do I work on PHP 5.6 / 5.7 and the >> corresponding beta APC version which at current rates of adoption might >> have begin to have an impact in the community sometime in the next 5 years, >> or (ii) work on a performance patch to the stable APC version which is >> typically installed with PHP 5.3 which these guys could apply within a few >> months. >> > > or contribute those patches back and integrate them into the vanilla apc? > > Humm. I think that we are sort of saying the same thing, but at cross > purposes. Of course I should offer any up patches for mainstream APC and at > best these will go into 3.1.14 or 3.1.15 and may then get adopted sometime > for production systems whenever -- that's only if the release of a core O+ > doesn't drop APC into legacy status. > no comment on that, but I'm expecting/hoping that we will keep apc alive at least until we have supported versions where O+ isn't in the core (5.3 and 5.4). > > However Ubuntu 12.04-LTS is a good example of a stable production stack > and this uses PHP 5.3.10 and APC 3.1.7. Debian Squeeze is even further > behind and it runs PHP 5.3.3 and APC 3.1.3. > > A performance patch could also be made available based on the last stable > version of APC, say 3.1.9 -- that is before the attempts to support the new > PHP 5.4 features destabilised it. With this patch, then at least > individual system admins would have the option to download a stable version > from PECL + patch it to use with their production stacks within the next > 3-6 months. > I still think that it would be better kept as a release, and that we should try to have a release which is stable with both 5.3 and 5.4, but it's easier said than done. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On 02/21/2013 04:42 PM, Keyur Govande wrote: Hi everyone, With the 2 weeks discussion period up, I'm moving this RFC to the Voting stage. I'd like to get this into 5.5. Most of the reaction has been positive and is archived here: http://marc.info/?t=13602158203&r=1&w=2 Please vote on https://wiki.php.net/rfc/cli_process_title. Voting ends on March 4, 2013. Thanks, Keyur. The patch is failing to link php in the current 5.5 snapshot, php5.5-201302221630. I did: $ cd php5.5-201302221630 $ patch --strip 1 < 280.patch patching file sapi/cli/config.m4 patching file sapi/cli/config.w32 patching file sapi/cli/php_cli.c patching file sapi/cli/php_cli_process_title.c patching file sapi/cli/php_cli_process_title.h patching file sapi/cli/php_cli_server.c patching file sapi/cli/php_cli_server.h patching file sapi/cli/ps_title.c patching file sapi/cli/ps_title.h patching file sapi/cli/tests/cli_process_title.phpt patching file sapi/cli/php_cli_process_title.c $ ./configure --disable-all [ . . . ] $ make [ . . . ] /bin/bash /home/cjones/Desktop/php5.5-201302221630/libtool --silent --preserve-dup-deps --mode=link cc -export-dynamic -g -O2 -fvisibility=hidden ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo ext/ereg/regex/regfree.lo ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/reflection/php_reflection.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_exceptions.lo ext/spl/spl_observer.lo ext/spl/spl_dllist.lo ext/spl/spl_heap.lo ext/spl/spl_fixedarray.lo ext/standard/crypt_freesec.lo ext/standard/crypt_blowfish.lo ext/standard/crypt_sha512.lo ext/standard/crypt_sha256.lo ext/standard/php_crypt_r.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/standard/password.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/output.lo main/getopt.lo main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo main/streams/filter.lo main/streams/plain_wrapper.lo main/streams/userspace.lo main/streams/transports.lo main/streams/xp_socket.lo main/streams/mmap.lo main/streams/glob_wrapper.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/z
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On 02/22/2013 10:22 AM, Christopher Jones wrote: On 02/21/2013 04:42 PM, Keyur Govande wrote: Hi everyone, With the 2 weeks discussion period up, I'm moving this RFC to the Voting stage. I'd like to get this into 5.5. Most of the reaction has been positive and is archived here: http://marc.info/?t=13602158203&r=1&w=2 Please vote on https://wiki.php.net/rfc/cli_process_title. Voting ends on March 4, 2013. Thanks, Keyur. The patch is failing to link php in the current 5.5 snapshot, php5.5-201302221630. Doh! buildconf is my friend. Thanks Johannes. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP User Survey
On Thu, Feb 21, 2013 at 9:24 PM, Christopher Jones wrote: > > > On 02/21/2013 03:02 AM, Florian Anderiasch wrote: >> >> On 02/21/2013 08:14 AM, Pierre Joye wrote: >> >>> I do not have a single doubt. Why? Surveys are one of many ways to get >>> feedback. They have no contracting values but give us some numbers about >>> one rfc or another. That may help us to focus on one feature instead of >>> another if we see a large number of users looking forward to it. >> >> >> You'll never get perfect results, but I prefer results at all over none :) >> >> There have been a lot of those for other languages: >> >> - >> >> http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ >> - http://survey.perlfoundation.org/ >> - http://survey.hamptoncatlin.com/ >> > > For the mail archives, there are also these (more focused) reports: > > http://static.zend.com/topics/zend-developer-pulse-survey-report-Q2-2012-0612-EN.pdf > > http://downloads.zend.com/guides/whitepapers/State_of_PHP_in_the_Enterprise_061212.pdf > > > Chris > > -- > christopher.jo...@oracle.com http://twitter.com/ghrd > Newly updated, free PHP & Oracle book: > http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hello, I see that people would rather agree with a RFC on polls on the website so I think we should rather get a RFC going and take it from there. I'll gladly make it if needed so just let me know. Also, maybe the conference organizers could help the PHP community by having surveys at the conference they are organizing and provide the feedback on their website. What do you think? Best regards. Florin Patan https://github.com/dlsniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On Thu, Feb 21, 2013 at 4:42 PM, Keyur Govande wrote: > Hi everyone, > > With the 2 weeks discussion period up, I'm moving this RFC to the Voting > stage. I'd like to get this into 5.5. > > Most of the reaction has been positive and is archived here: > http://marc.info/?t=13602158203&r=1&w=2 Just out of curiosity, I don't see it covered in the other thread; Is there a reason why it cannot support sapi/fpm? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On 02/22/2013 11:48 AM, Hannes Magnusson wrote: > On Thu, Feb 21, 2013 at 4:42 PM, Keyur Govande wrote: >> Hi everyone, >> >> With the 2 weeks discussion period up, I'm moving this RFC to the Voting >> stage. I'd like to get this into 5.5. >> >> Most of the reaction has been positive and is archived here: >> http://marc.info/?t=13602158203&r=1&w=2 > > Just out of curiosity, I don't see it covered in the other thread; Is > there a reason why it cannot support sapi/fpm? fpm has its own implementation already. I suppose we could swap out the one in fpm and replace it with this one, but that seems like a separate decision. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On Fri, Feb 22, 2013 at 11:52 AM, Rasmus Lerdorf wrote: > On 02/22/2013 11:48 AM, Hannes Magnusson wrote: >> On Thu, Feb 21, 2013 at 4:42 PM, Keyur Govande >> wrote: >>> Hi everyone, >>> >>> With the 2 weeks discussion period up, I'm moving this RFC to the Voting >>> stage. I'd like to get this into 5.5. >>> >>> Most of the reaction has been positive and is archived here: >>> http://marc.info/?t=13602158203&r=1&w=2 >> >> Just out of curiosity, I don't see it covered in the other thread; Is >> there a reason why it cannot support sapi/fpm? > > fpm has its own implementation already. I suppose we could swap out the > one in fpm and replace it with this one, but that seems like a separate > decision. Right, which makes me worry about the function name.. cli_*. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On Fri, Feb 22, 2013 at 2:59 PM, Hannes Magnusson < hannes.magnus...@gmail.com> wrote: > On Fri, Feb 22, 2013 at 11:52 AM, Rasmus Lerdorf > wrote: > > On 02/22/2013 11:48 AM, Hannes Magnusson wrote: > >> On Thu, Feb 21, 2013 at 4:42 PM, Keyur Govande > wrote: > >>> Hi everyone, > >>> > >>> With the 2 weeks discussion period up, I'm moving this RFC to the > Voting > >>> stage. I'd like to get this into 5.5. > >>> > >>> Most of the reaction has been positive and is archived here: > >>> http://marc.info/?t=13602158203&r=1&w=2 > >> > >> Just out of curiosity, I don't see it covered in the other thread; Is > >> there a reason why it cannot support sapi/fpm? > > > > fpm has its own implementation already. I suppose we could swap out the > > one in fpm and replace it with this one, but that seems like a separate > > decision. > > Right, which makes me worry about the function name.. cli_*. > > -Hannes > If FPM wants to use these too, the implementation can be easily shared and the wrappers around these can be created and called php_fpm_*. The reason for CLI in the names was to indicate the limited availability of these methods.
[PHP-DEV] rfc:trailing-comma-function-args
I've been thinking about this RCF for a while now:
https://wiki.php.net/rfc/trailing-comma-function-args
It just doesn't seem necessary - the only time I've ever found something
like this to be necessary, is when a function takes closures or other very
long arguments, some of which are optional... but actually, writing this in
a VCS-friendly way is already possible:
$tree->traverse(
$tree
,
function($node) {
// ...
}
);
... version 2 ...
$tree->traverse(
$tree
,
function($node) {
// ...
}
,
function($node) {
// ...
}
);
This actually comes out more legible, in my opinion.
What really irks me about this patch, is that the trailing comma implies
that another optional argument may exist - it really doesn't make the code
more intuitive to read. The example on the page (using fopen) really isn't
a realistic use-case - who would break a couple of simple arguments into
individual lines like that?
Just my two cents...
- Rasmus
Re: [PHP-DEV] rfc:trailing-comma-function-args
2013/2/22 Rasmus Schultz
> I've been thinking about this RCF for a while now:
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> It just doesn't seem necessary - the only time I've ever found something
> like this to be necessary, is when a function takes closures or other very
> long arguments, some of which are optional...
I must say, that I find this RFC completely useless. In my opinion when one
has such a long parameter list (or too long variable names),
that he must break the call onto several lines, the additional line in the
vcs' diff is the minor problem.
> but actually, writing this in
> a VCS-friendly way is already possible:
>
> $tree->traverse(
> $tree
> ,
> function($node) {
> // ...
> }
> );
>
> ... version 2 ...
>
> $tree->traverse(
> $tree
> ,
> function($node) {
> // ...
> }
> ,
> function($node) {
> // ...
> }
> );
>
> This actually comes out more legible, in my opinion.
>
> What really irks me about this patch, is that the trailing comma implies
> that another optional argument may exist - it really doesn't make the code
> more intuitive to read. The example on the page (using fopen) really isn't
> a realistic use-case - who would break a couple of simple arguments into
> individual lines like that?
>
/sign
Especially about the "implies, that another optional argument may exist":
One does not simply add arbitrary arguments to a function call. Except when
the function signature changes, but in this case (to repeat myself) the
additional diff-line is negligible.
>
> Just my two cents...
>
My too
>
> - Rasmus
>
--
github.com/KingCrunch
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 19/02/13 01:30, Kevin Yung wrote: In our environment, we use NFS for shared storage, we are using APC as well with stat=0. In our setting, we also experiencing high number of stat() calls on our file system. My initial finding of this problem is we enabled the open_basedir setting. And there is already a bug report for this, https://bugs.php.net/bug.php?id=52312 We tested the issue in 5.2.x, 5.3.x and 5.4.x, all of them experiencing same issue. Kevin, I've just walked through this in 5.3 and 54 and updated this bugrep. In short there is some silly coding here which should be addressed. Even if we accept that PHP should comply with http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5178 if open_basedir is set, then the cache should only be ignored on the actual open itself, as this is the only one that is exploitable, but let's have this debate on the bugrep. Let me think about the security and other NFRs and propose a patch.
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hey Dmitry, I noticed today that ZO+ doesn't make use of sapi_get_stat()
to get the initial stat struct from the sapi if available. So, if you
have top-level a.php that includes b.php and c.php you end up with:
stat("/var/www/a.php", {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat("/var/www/a.php", {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat("/var/www/b.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
stat("/var/www/c.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
whereas with APC you have:
stat("/var/www/a.php", {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat("/var/www/b.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
stat("/var/www/c.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
That initial stat on a.php is done by Apache and because ZO doesn't grab
that existing stat struct from the sapi it has to re-stat the top-level
script.
Was this an intentional thing to leave out or just an oversight?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/22/2013 07:57 PM, Rasmus Lerdorf wrote:
> Hey Dmitry, I noticed today that ZO+ doesn't make use of sapi_get_stat()
> to get the initial stat struct from the sapi if available. So, if you
> have top-level a.php that includes b.php and c.php you end up with:
>
> stat("/var/www/a.php", {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
> stat("/var/www/a.php", {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
> stat("/var/www/b.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
> stat("/var/www/c.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
>
> whereas with APC you have:
>
> stat("/var/www/a.php", {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
> stat("/var/www/b.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
> stat("/var/www/c.php", {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
>
> That initial stat on a.php is done by Apache and because ZO doesn't grab
> that existing stat struct from the sapi it has to re-stat the top-level
> script.
>
> Was this an intentional thing to leave out or just an oversight?
A very quick a lightly-tested implementation:
https://github.com/zend-dev/ZendOptimizerPlus/pull/40
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
