Re: [PHP-DEV] Re: Hold off 5.4
Who says it has to be 5.4? People seem to be a bit fixated on the version there. Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. ---Jani On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote: On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner m...@php.net wrote: On 11/23/2010 02:30 AM, Felipe Pena wrote: 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. The reality is that trunk is not going to be 5.4; it cannot be in its current state. The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing. The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This is an unreliable, laborious, crappy method for creating stable branches, and managing the repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and re-integrating is also a pretty crappy solution. So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work. Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now. We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories to more easily pull those changes into the appropriate branches. - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
hi Andi, On Thu, Nov 25, 2010 at 7:42 AM, Andi Gutmans a...@zend.com wrote: I agree with that. More structure and predictability will be very valuable to the project. We created a lot of structure in Zend Framework and it has really paid off. Btw, we don't have to look far. Just the change in having people document their suggestions via RFCs already had a substantial impact on this project both in terms of peer review and having a long lasting trail of what made it into a given release. More structure will typically yield in higher quality, more visibility and therefore more motivation for people to contribute, and I believe also in more deliverables rather than less as people will work towards clear goals + be accepting if they miss them and they need to wait for the next release train. As we will stay flexible, a fixed time time to begin with is better. The other key part was about features selection, unlike what has been done (or suggested in this thread), we should take what is done but what we what is ready and desired. Desired as in tested (viable, BC, QAs, etc.) and desired (RFC, votes, etc.). A fixed time line also helps developers to catch the next band wagon if they miss one, instead of pushing in half backed additions. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: git anyone?
On 2010-11-25, Pierre Joye pierre@gmail.com wrote: hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Cheers, I liked the DVCS idea back when we switched to SVN and I still like it. It is good to have the perspective of switching over to a DVCS in the future if developers want to. But we need to make sure that a few topics are sorted out before. In particular - Karma System Although you can use DVCS in a centralized fashion they are much better when it comes to the ..distributed.. part. We either need to change the way we develop towards a more push/pull mechanism or implement the karma system. - Easy Access I don't think that's a big deal at all. Developers who can learn how to write PEAR/PECL, PHP-SRC code probably know how to learn a tool. For the rest, we successfully installed read-only Git-SVN bridges at phpBB when Nils Adermann and I did their migration. - Hosting Rasmus was thinking about using github. - Less Learning Curve Ah, I think Git reached the masses and people become more and more able to deal with Git. Anyway, still Git is a swiss army knife with a big red boom button on top of it from time to time. - A few old timers didn't want us using Git They'll get over it. If someone is interested in moving into the direction of using a DVCS, this is either Git or Mercurial, I'm happy to help with evaluation and migration. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Wed, 2010-11-24 at 21:46 -0800, Stas Malyshev wrote: However, there are a lot of practical challenges (auth, etc.) that need to be solved. I think one of the biggest issues is PHP extension handling. All ways for moving extensions in/out while keeping history are annoying. Doing all in sub-modules would be damn annoying ... that certainly needs evaluation before a switch. Other than that I really love git :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
I really like Git (much more than SVN actually) and I use it for all my projects, but I doubt moving to Git would solve anything. IMO even CVS was quite enough for our development model. On 11/25/2010 04:47 AM, Pierre Joye wrote: hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Cheers, -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
the branching/merging is much better, so if not anything, but could solve/make thing easier, especially if we decide to work with more branches (either for cherry picking, or multiple stable branches, for example the suggested lts method) On Thu, Nov 25, 2010 at 10:39 AM, Antony Dovgal t...@daylessday.org wrote: I really like Git (much more than SVN actually) and I use it for all my projects, but I doubt moving to Git would solve anything. IMO even CVS was quite enough for our development model. On 11/25/2010 04:47 AM, Pierre Joye wrote: hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Cheers, -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
GIT is realy nice! git merging magic!
Re: [PHP-DEV] git anyone?
On 25/11/10 07:41, Lester Caine wrote: Patrick ALLAERT wrote: 2010/11/25 Lester Caineles...@lsces.co.uk: Have you used git on Windows Pierre ... It is a joke! Yes one can get it to work, but only if you do not use anything that the git cygwin install destroys! And as yet there is no consensus on getting it working cross platform in things like Eclipse. At least hg works out of the box on both linux and windows, but like git THAT does not properly support sub-repo's and makes managing nice modularly constructed projects like PHP almost impossible. Trying to work with projects that write modular PHP code in either git or hg is simply not currently practical ... especially when half of your user base is still tied to windows! Git on Windows problems belong to the past since a while now: * mSysGit Provide you don't use cygwin ALREADY on your machine !!! Install mSysGit and existing packages stop working ... While I don't use Windows, I do know that msysgit keeps things separate and shouldn't clobber your cygwin setup. Perhaps you have an issue with your path? The state of Git on Windows is, yes, far from perfect, but certainly improving. A quick search yields up some nice looking tools for Git on Windows: http://www.makeuseof.com/tag/5-windows-git-clients-git-job/ SmartGit looks pretty good (non-commercial use). Git on Windows is not 100% friendly, but is workable. We have people using it everyday at work here. * TortoiseGit TortoiseHg does it RIGHT and works on both Linux and Windows. TortoiseGit does not work on Linux ... I use Linux and quite frankly I couldn't give a damn about things like Tortoise*. Such tools are nice enough for Windows where command prompt is so desperately useless, but they are no substitute for a real understanding of the command line interface of the SCM tool. I have a decent command prompt in Linux and it is a hell of a lot quicker (and, I would say, easier) to use. In short - I'm not sure why you're trying to slag off Git because TortoiseGit is no good for Linux. What is wrong with git-gui, gitk or gitg? Personally I run hg since I need cross platform capability for my customers, and hggit quite happily links to github but all of this has to be managed outside Eclipse since none of those tools work reliably. And we STILL have the problem of handling modular projects since neither do 'sub-repo' reliably. This area seems to be in a similar state of chaos to PHP with different factions all pushing their own agendas. Both git and hg are targeting compiled applications and ignore handing scripted applications like php, python, ruby and the like. 'You fix the problems when you build a project' simply does not work when you do not have anything to build! So while it may work for building PHP as a single program, a packaged distribution is a different matter. Ultimately I'm a +1 for Git. The proper branching/merging would solve so many issues that have been addressed recently on the mailing list regarding the pollution of trunk with incomplete and broken features, as well as BC breakage by feature removal... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Nick Pope wrote: Ultimately I'm a +1 for Git. The proper branching/merging would solve so many issues that have been addressed recently on the mailing list regarding the pollution of trunk with incomplete and broken features, as well as BC breakage by feature removal... I have been using Eclipse for development for several years, and PHPEclipse does everything I need. CVS and SVN simply work ... fully integrated ... and BeyondCompare handles all of the 'merge' problems that a simple update or manual merge has trouble with. For that reason I have never had a problem with 'merging'. Eclipse works transparently in linux and windows ... it is the reason that I started using it in the first place. I do not have to think 'linux ... commmand line'/'windows ... need something else' Neither GIT nor HG integration works with Eclipse so I have to drop outside Eclipse to handle picking up changes from github, and for HG, the graphics tools simply work transparently. BUT in reality the broken Eclipse in integration needs to be repaired if these projects are to really support a replacement of CVS and SVN. I have wasted weeks of possible real coding time trying to get git working for *ME* and I'm not going to spend any more until it is available as a working plugin for Eclipse. I AM using HG but simply as it was the only way to remain in touch with my main commercial activities since those developers forced a change to github. I would strongly agree with the statement that CVS is ideal for PHP since that at least has a working package management system which has worked for years. Managing merges is NOT a problem if you are used to tools which fix the problem, in much the same way as third party plugins already try to do in git and hg! Currently importing a CVS project into either git or hg creates an essentially unusable mess since the package management is no longer avialable. How do you combine a 200 package CVS project which gets mapped to 200 repos to create a single distributable project in ANY DVCS system? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: git anyone?
On 25.11.2010 10:20, David Soria Parra wrote: - A few old timers didn't want us using Git They'll get over it. The great thing is... that git can work as an svn client or You can work with svn client on a github git repo ( afair ? ) ;-) - Krzysztof -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Hold off 5.4
On 2010-11-23, Felipe Pena felipe...@gmail.com wrote:
--001636eef065b3eaf30495ae5198
Content-Type: text/plain; charset=UTF-8
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 {}
As Matthew pointed out, I consider this a pretty grave BC break.
- 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.
+1, I agree. We should hold 5.4 off until we have at least a sane
release process and solve the type hinting question.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Release Process
On 2010-11-23, Felipe Pena felipe...@gmail.com wrote: --001636eef06580573f0495ae312f Content-Type: text/plain; charset=UTF-8 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 thanks for preparing this, as matthew and andi pointed out, more structure is a good idea. I still think even with all the things in the RFC in place, we are still very flexible. Having planned releases and clear processes how to reduce BCs and add transparency was always a good thing in the projects I worked on. So I'm definatly in favor of this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 25/11/10 10:14, Lester Caine wrote: Nick Pope wrote: Ultimately I'm a +1 for Git. The proper branching/merging would solve so many issues that have been addressed recently on the mailing list regarding the pollution of trunk with incomplete and broken features, as well as BC breakage by feature removal... I have been using Eclipse for development for several years, and PHPEclipse does everything I need. CVS and SVN simply work ... fully integrated ... and BeyondCompare handles all of the 'merge' problems that a simple update or manual merge has trouble with. For that reason I have never had a problem with 'merging'. I wasn't really referring to the diff tools like BeyondCompare. I was referring to having a SCM tool that does *proper* branching and merging. Git does, SVN really doesn't. Git is incredibly flexible when it comes to branching. It is also space efficient which is useful on large projects - a branch isn't a complete copy. Git is faster/distributed - doesn't require access to the remote repository to perform a diff/merge - useful if you are without network access. And generally operations are quick because they occur on blobs that contain just the changes rather than the entire source tree. Eclipse works transparently in linux and windows ... it is the reason that I started using it in the first place. I do not have to think 'linux ... commmand line'/'windows ... need something else' Fair enough regarding eclipse... I wasn't slamming it, I just don't use it. And I don't really find that lack of SCM integration in IDE is the end of the world. But if you are using msysgit which uses a bash shell for running command line Git... You don't have to think any different. Neither GIT nor HG integration works with Eclipse so I have to drop outside Eclipse to handle picking up changes from github, and for HG, the graphics tools simply work transparently. BUT in reality the broken Eclipse in integration needs to be repaired if these projects are to really support a replacement of CVS and SVN. I really couldn't make sense of this. Also - did you actually read my last reply? The link I sent you linked to this: http://www.eclipse.org/egit/ I've never used it. I can't vouch for it. But if that isn't some form of integration, I don't know what is. I have wasted weeks of possible real coding time trying to get git working for *ME* and I'm not going to spend any more until it is available as a working plugin for Eclipse. I AM using HG but simply as it was the only way to remain in touch with my main commercial activities since those developers forced a change to github. Fair enough. I just can't really see that there is that much of a problem with Git. It has rough edges on Windows as I've said in my last reply. Again - there is a plugin. I would strongly agree with the statement that CVS is ideal for PHP since that at least has a working package management system which has worked for years. Managing merges is NOT a problem if you are used to tools which fix the problem, in much the same way as third party plugins already try to do in git and hg! Currently importing a CVS project into either git or hg creates an essentially unusable mess since the package management is no longer avialable. How do you combine a 200 package CVS project which gets mapped to 200 repos to create a single distributable project in ANY DVCS system? Seriously? CVS is painful. Back when I first looked into SCM I brushed on it and skipped straight to SVN. Managing merges is NOT a problem if you are used to tools which fix the problem... That goes without saying for pretty much any SCM tool. ...in much the same way as third party plugins already try to do in git and hg! Third-party plugins?! That's news to me. I think you mean use of an external program that already handles diffs/merges. Why reinvent the wheel. And you were going on about BeyondCompare. Would that not be exactly the same. Currently importing a CVS project into either git or hg creates an essentially unusable mess... In my opinion it was in a mess in the first place... ...working package management system... I presume this is multiple projects in a single repository? Yes, Git doesn't have that. Again - it just sounds like a mess to me. I've never had to have a package management system in a SCM repository myself before, so I guess I cannot comment too strongly on this. However, submodules do work quite nicely. I won't pretend that they are a perfect solution in every case because the are tied by commit. Anyone who doesn't want the cruft can ignore them. The PHP repository could probably do with some level of segmentation anyway - it is one giant monolithic beast at the moment. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
2010/11/25 Jani Taskinen jani.taski...@iki.fi: Who says it has to be 5.4? People seem to be a bit fixated on the version there. I'd like to know too... Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Well, such a change tends to create a big buzz, without mentioning stuff like certifications, trainings,... We should avoid creating a virtual PHP 6.0 which will contain all the BC stuff while all features appears in 5.x. By doing so we will keep some shit in 5.x forever and won't have anything appealing enough to migrate to 6.0! Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. ---Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, Nov 25, 2010 at 12:47 PM, Lester Caine les...@lsces.co.uk wrote: ( And installing msysgit broke ssh access to my customer sites from the windows box. A couple of days working on fixing that produced no solution, while simply un-installing it restored all of the broken functionality. It was a few months ago, but I don't believe anything ha changed so I will not be wasting time on it until someone says that msysgit is now working with an existing putty/secure key setup ... What I have has worked for years and git broke it! ) As this is off topic, the question is about using git for php.net, not really about how to do break a windows setup :) I use cygwin, msys, msysgit (separate install) and putty on the same machines, without any special issues. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 25/11/10 11:47, Lester Caine wrote: Nick Pope wrote: I really couldn't make sense of this. Also - did you actually read my last reply? The link I sent you linked to this: http://www.eclipse.org/egit/ I've never used it. I can't vouch for it. But if that isn't some form of integration, I don't know what is. Please check fact before posting 'solutions' ... egit does not ACTUALLY fully work hence the main reason it is still an incubation project. The main problem is that jgit on which it is based does not current support sub-repo, and as soon as there is a sub-repo in the target then nothing works! Granted it doesn't *fully* work. You said Neither GIT nor HG integration works with Eclipse... and I disagreed. You just told me that it doesn't fully work. Thus it must do to some extent... What you mean is that it currently doesn't work for you. ... and I'm not going to spend any more until it is available as a working plugin for Eclipse. That is fine - I'd just use the command line and be done with it to be honest. I never found even the SVN eclipse integration to be all that wonderful either. Each to their own. ...working package management system... I presume this is multiple projects in a single repository? Yes, Git doesn't have that. Again - it just sounds like a mess to me. I've never had to have a package management system in a SCM repository myself before, so I guess I cannot comment too strongly on this. However, submodules do work quite nicely. I won't pretend that they are a perfect solution in every case because the are tied by commit. Anyone who doesn't want the cruft can ignore them. The PHP repository could probably do with some level of segmentation anyway - it is one giant monolithic beast at the moment. sub-repo STILL needs work to allow a SINGLE download of a clone complex repo. PHP is a number of packages which combine to provide a single distribution, and packages can be added as required. It is not a single monolithic beast. Either the whole modular setup is imported into a single git repo, or each package has it's own repo. It is THEN that the holes in sub-repo management become a problem! I said that the SVN repository is just a single glob of everything: PHP, PECL stuff, etc... ( And installing msysgit broke ssh access to my customer sites from the windows box. A couple of days working on fixing that produced no solution, while simply un-installing it restored all of the broken functionality. It was a few months ago, but I don't believe anything ha changed so I will not be wasting time on it until someone says that msysgit is now working with an existing putty/secure key setup ... What I have has worked for years and git broke it! ) Uhh... I can tell you now that msysgit and putty are fine together... With public keys. Because my colleagues use it every day. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 25/11/10 12:22, Pierre Joye wrote: On Thu, Nov 25, 2010 at 12:47 PM, Lester Caineles...@lsces.co.uk wrote: ( And installing msysgit broke ssh access to my customer sites from the windows box. A couple of days working on fixing that produced no solution, while simply un-installing it restored all of the broken functionality. It was a few months ago, but I don't believe anything ha changed so I will not be wasting time on it until someone says that msysgit is now working with an existing putty/secure key setup ... What I have has worked for years and git broke it! ) As this is off topic, the question is about using git for php.net, not really about how to do break a windows setup :) I use cygwin, msys, msysgit (separate install) and putty on the same machines, without any special issues. Cheers, Agreed. Sorry. Was just trying to say that I really don't think that support for Windows is an issue. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
Slightly brambly thoughts... I think (imho) the PHP6 hype in user land died down long ago after it became obvious it wouldn't materialise any time soon. It would be nice to see 6 to appear if only to break the (apparent) deadlock that the Unicode stuff brought on(I realise this is not enough justification by itself) What will this mean to all the Hosting providers etc who are still finishing long running 4-5 or 5.x - 5.3 migrations? Will they resist change more because it looks like a bigger change regardless of the underlying code? As they provide installs/hosting for what I can guess to be a huge amount of the PHP's actual users is it factor that's worth considering I realise this is a Friday afternoon category comment but it can't wait.. Think of all of those PHP6 books that will be reduced to near junk status in swift branch/commit action And as a bonus -Original Message- From: Jani Taskinen [mailto:jani.taski...@iki.fi] On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote: 2010/11/25 Jani Taskinen jani.taski...@iki.fi: Who says it has to be 5.4? People seem to be a bit fixated on the version there. I'd like to know too... Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Well, such a change tends to create a big buzz, without mentioning stuff like certifications, trainings,... This is a joke, right? We should avoid creating a virtual PHP 6.0 which will contain all the BC stuff while all features appears in 5.x. By doing so we will keep some shit in 5.x forever and won't have anything appealing enough to migrate to 6.0 ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for fancy new stuff. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
May I ask not to begin with that again? The php 2034 thing? Let sort out what has to be sorted out, like the current proposals. In the short term, a 5.x (with BC) is what users and developers are looking for. We can then begin to think about the next big step. On Thu, Nov 25, 2010 at 1:58 PM, James Butler james.but...@edigitalresearch.com wrote: Slightly brambly thoughts... I think (imho) the PHP6 hype in user land died down long ago after it became obvious it wouldn't materialise any time soon. It would be nice to see 6 to appear if only to break the (apparent) deadlock that the Unicode stuff brought on(I realise this is not enough justification by itself) What will this mean to all the Hosting providers etc who are still finishing long running 4-5 or 5.x - 5.3 migrations? Will they resist change more because it looks like a bigger change regardless of the underlying code? As they provide installs/hosting for what I can guess to be a huge amount of the PHP's actual users is it factor that's worth considering I realise this is a Friday afternoon category comment but it can't wait.. Think of all of those PHP6 books that will be reduced to near junk status in swift branch/commit action And as a bonus -Original Message- From: Jani Taskinen [mailto:jani.taski...@iki.fi] On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote: 2010/11/25 Jani Taskinen jani.taski...@iki.fi: Who says it has to be 5.4? People seem to be a bit fixated on the version there. I'd like to know too... Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Well, such a change tends to create a big buzz, without mentioning stuff like certifications, trainings,... This is a joke, right? We should avoid creating a virtual PHP 6.0 which will contain all the BC stuff while all features appears in 5.x. By doing so we will keep some shit in 5.x forever and won't have anything appealing enough to migrate to 6.0 ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for fancy new stuff. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010, Davey Shafik wrote: The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Four branches? Are you going to help? Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. That's a good theoretical point of view. And I maintain it doesn't work. It makes it for example very difficult to try out multiple new features at the same time; to say, to try to figure our whethr your app will still works. It's also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible (that's also why I am not a fan of DVCS, because it reduces that exposure drastically). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, 25 Nov 2010, Pierre Joye wrote: We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. Before even talking about git; the discussion should focus on whether we want DVCS. There are other things out there beside gits, which are not that difficult to use and provide just as much functionality. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Revise callback Psuedo-type to support new Closure class ?
On 24 November 2010 18:03, Nathan Nobbe quickshif...@gmail.com wrote:
Ummm... never mind!
Sorry for the noise!
-nathan
On Wed, Nov 24, 2010 at 11:00 AM, Nathan Nobbe quickshif...@gmail.comwrote:
Hi all,
I had a thought this morning and would like some feedback. Don't you think
it would make sense to allow the callback psuedo-type to also allow the new
Closure class to be an acceptable data type? A simple example that would be
nice to have working would be
?php
$fClosure = function($val, $key) {
echo $key = $val . PHP_EOL;
}
$aNumbers = array(5, 4, 3, 2, 1);
array_walk($aNumbers, $fClosure);
?
Thoughts ?
-nathan
I bet you thought you had something there... Ha!
It is a pity that the error is tagged as being on line 6 and not line 4.
I can see why. It isn't an error until the first non ; following the
closing brace (excluding comments).
So ...
$fn = function()
// comment
;
is valid.
Having the error on the same line as the closing brace would be nice though.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Derick Rethans wrote: On Thu, 25 Nov 2010, Pierre Joye wrote: We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. Before even talking about git; the discussion should focus on whether we want DVCS. There are other things out there beside gits, which are not that difficult to use and provide just as much functionality. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Ignoring the problems of actually using github I think this is exactly the problem we are finding with those projects that have pushed over to git. MANAGING what is allowed back into some master copy of the code base is the bit that is a lot more difficult than with current arrangements. The result is several versions of the same projects simply because people are doing their own things and then nobody knows which version to pull from. The release manager has to un-pick what should be merged and even on a small project this is time consuming. If everybody with their own agenda for PHP starts doing their own builds we will end up with even more branches since they will just be publishing them ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 25 November 2010 07:16, Patrick ALLAERT patrickalla...@php.net wrote: TortoiseGit So, I now have TortoiseCVS, TortoiseSVN _and_ TortoiseGit. Gee! My windows is slow enough ... now I'm pulling along 3 tortoises. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, Nov 25, 2010 at 3:26 PM, Lester Caine les...@lsces.co.uk wrote: Derick Rethans wrote: On Thu, 25 Nov 2010, Pierre Joye wrote: We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. Before even talking about git; the discussion should focus on whether we want DVCS. There are other things out there beside gits, which are not that difficult to use and provide just as much functionality. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Ignoring the problems of actually using github I think this is exactly the problem we are finding with those projects that have pushed over to git. MANAGING what is allowed back into some master copy of the code base is the bit that is a lot more difficult than with current arrangements. The result is several versions of the same projects simply because people are doing their own things and then nobody knows which version to pull from. The release manager has to un-pick what should be merged and even on a small project this is time consuming. If everybody with their own agenda for PHP starts doing their own builds we will end up with even more branches since they will just be publishing them ;) http://progit.org/book/ch5-1.html I think we could go with either an Integration Manager kind of workflow, or with the Dictator and Lieutenants (that is used for the linux development). either way, with good merging tools, the integrations isn't such of a problem. my 2 cents.
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans der...@php.net wrote: On Thu, 25 Nov 2010, Davey Shafik wrote: The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. Yes, cherry picking is not as easy as people assume they are, because many changes depend on each other and trunk has a fair quantity of these. I think trunk should be the starting point for 5.4; as to type hinting, I'm neutral as to the status quo. However, this is all orthogonal to this thread, what's important is that we agree on the formalities proposed so that we can proceed to these material issues. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Mon, 22 Nov 2010, Felipe Pena wrote: [1] http://wiki.php.net/rfc/releaseprocess Now I've thought a bit more about it, I'm trying to reply to this with some constructive comments. I'm reordering it a bit in the response where it makes sense to do. In a general way, some of the things in here are done, and IMO it make sense to refine them during the 5.4 process if we find that things don't work as this theoretical RFC implies. = Releases Cycle = No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis. Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6. Binary compatibility can be broken between two features releases, f.e. between 5.3 and 5.4: * x.y.z to x.y.z+1 * Bugs fixes only (with a room for exceptions on a case by case basis and only for small self contained features additions). * Extensions support can't be removed (like move them to pecl) * Backward compatibility must be kept (internals and userland) * ABI/API compatibility must be kept (internals) * x.y.z to x.y+1.z * Bugs fixes * New features * Extensions support can be ended (moved to pecl) * Backward compatibility must be kept * API compatibility must be kept (internals and userland) * ABI can be broken (internals) * x.y.z to x+1.0.0 * Bugs fixes * New features * Extensions support can be ended (moved to pecl) * Backward compatibility can be broken * API compatibility can be broken (internals and userland). * ABI can be broken (internals) It is critical to understand the consequences of breaking BC, APIs or ABIs. It should not be done for the sake of doing it. RFCs explaining the reasoning behind a breakage and the consequences along with test cases and patch(es) should help. The whole section above is really nothing new, but good to write down. * Yearly release cycle * 3 years release life cycle * 2 years bugs fixes only * 1 year security fixes only Example time line with only one major version at a time code pre release phase release lifetime with all bugs fixes, no feature addition release lifetime security fixes only DEOL Version Time - 20112012 2013 201420152016 2017 | | | | | | | | | | | | | 5.3 +-D 5.4 |*+---D 5.5 | | |**---D 5.6 | | | | |**---D 6.0 | | | | |**---D 6.1 | | | | |**---D /code Example time line with two majors versions However it could happen that a new major version is desired while the active major version is still heavily used. Like what we had between php 4 and 5 or for the oldest, between php 3 and 4. Because of this, Perhaps the latest release before a new major one should run for a year longer. So in the example above, 5.6 runs until where 6.0 ends too. code pre release phase release lifetime bugs release lifetime security only DEOL Version Time - 20112012 2013 201420152016 2017 | | | | | | | | | | | | | 5.3 +-D 5.4 |*+---D | | | | | 5.5 | | |**---D | | | 5.6 | | | |**---D 6.0 | | |**---D | | 6.1 | | | |**---D /code This variant is not workable, because there are (in the example) in 2014 *five* branches. Merging between those, manually and automatically is going to be a major pain. I'd say we all rather want to focus our time on fixes and new features; and not spend more time doing branch merging, whatever tool we use for this. Timeline example for a release * January * Decisions which features or changes will be in the next release * 1st release alpha (may have many alpha) * At least one release per month, more at wish * March, RC phases, biweekly release * each RC should go through the QA before being published * usually2 days Uh? The whole RC phase is QA. I don't see why you need another QA 'period'. I would however want to say that packaging and bundling is done on Wednesday, with any release on Thursday
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010, Gustavo Lopes wrote: On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans der...@php.net wrote: On Thu, 25 Nov 2010, Davey Shafik wrote: The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. Yes, cherry picking is not as easy as people assume they are, because many changes depend on each other and trunk has a fair quantity of these. I think trunk should be the starting point for 5.4; as to type hinting, I'm neutral as to the status quo. Yes, I also think trunk should be 5.4. It's not the most ideal thing though, but something we'll have to live with. It's going to be a lot less of a hassle than cherry picking trunk's features and graft them onto 5.3. However, this is all orthogonal to this thread, what's important is that we agree on the formalities proposed so that we can proceed to these material issues. I don't know. The release process discussion can run at the same time and be ready for 5.5. That even allows us to refine it while we're trying out the current proposal. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, 25 Nov 2010, Ferenc Kovacs wrote: On Thu, Nov 25, 2010 at 3:26 PM, Lester Caine les...@lsces.co.uk wrote: Derick Rethans wrote: On Thu, 25 Nov 2010, Pierre Joye wrote: Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Ignoring the problems of actually using github I think this is exactly the problem we are finding with those projects that have pushed over to git. MANAGING what is allowed back into some master copy of the code base is the bit that is a lot more difficult than with current arrangements. The result is several versions of the same projects simply because people are doing their own things and then nobody knows which version to pull from. The release manager has to un-pick what should be merged and even on a small project this is time consuming. If everybody with their own agenda for PHP starts doing their own builds we will end up with even more branches since they will just be publishing them ;) http://progit.org/book/ch5-1.html I think we could go with either an Integration Manager kind of workflow, or with the Dictator and Lieutenants (that is used for the linux development). either way, with good merging tools, the integrations isn't such of a problem. Whatever workflow we prefer is not what is guaranteed to happen. I agree totally with Lester here. DVCS fragments the development team. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Wed, 24 Nov 2010, Philip Olson wrote: Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. The main reasons we moved to SVN and not Git include: - Less of a learning curve, because SVN is like CVS - Most of the CVS-SVN work was already finished - A few old timers didn't want us using Git - We aren't sure how the authentication/karma system would work Most people wanted (and still want) to move to Git, but moving to SVN was a simpler process. Any proposal towards Git should include how it'd work. Also, Github (yes or no) is another part of this. Git is *not* the only DVCS either! The others (mercurial, bazaar) should also be looked at. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Developers can already wall themselves off now with the github mirror. Also, taking a peak at the linux dev mailing list I see lots of collaboration going on. It makes sense that a developer wanting to discuss a new feature or patch will push that branch to origin. What a DVCS does allow for are branches for each specific project/patch and incremental commits within that branch. That keeps project/patch commits together and also side-steps the entire issue of cherry-picking. At work we use git and usually have 6 project branches with competing and interweaving timeframes. Each developer has upwards of 50 branches local to them (heck I recently had 105 until I did some cleaning yesterday) that feed the project branches. We manage this with very few problems and is not something we could do with cvs or svn. Ignoring the problems of actually using github I think this is exactly the problem we are finding with those projects that have pushed over to git. MANAGING what is allowed back into some master copy of the code base is the bit that is a lot more difficult than with current arrangements. The result is several versions of the same projects simply because people are doing their own things and then nobody knows which version to pull from. The release manager has to un-pick what should be merged and even on a small project this is time consuming. If everybody with their own agenda for PHP starts doing their own builds we will end up with even more branches since they will just be publishing them ;) http://progit.org/book/ch5-1.html I think we could go with either an Integration Manager kind of workflow, or with the Dictator and Lieutenants (that is used for the linux development). either way, with good merging tools, the integrations isn't such of a problem. Whatever workflow we prefer is not what is guaranteed to happen. I agree totally with Lester here. DVCS fragments the development team. DVCS does not cause fragmentation. DVCS is a tool. How a development team uses that tool is up to them. I don't think anyone seriously considering a migration to git is thinking that there are no problems. However, the problems Lester is describing are similar to the problems we have now: people checked in all kinds of changes to trunk and nobody knows how to pick them apart to make a stable build. In my experience, managing DVCS is less work than managing cvs/svn. Sure, individuals and entire development teams can shoot themselves in the foot if they use DVCS incorrectly. But, I would rather use a sharp tool (like git) than a dull one (like svn). -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Runtime-Extension of Classes
Hello out there!
This morning I asked myself whether it's possible to extend a class without
calling the child, but the initially extended class?
It can, in some circumstances, really be important.
I.e.: I build an CLI-shell interface for some back-end stuff I'd to do - and
it really is a pain in the ass to do all of the include-register-calls' for
each of a newly written extension. It could be so much easier, considered
having a possibility to do the include-[I'm usable] way ;)
I mean, for instance:
?
interface XorePwnI {
public function XorePwn ( $_uu, $_xw );
/*
...
*/
}
class XorePwn implements XorePwnI {
public function XorePwn ( $_uu, $_xw ) {
return true;
}
}
class XorePwn_Intruder extends XorePwn {
public function CorePwn ( $_uu, $_xw ) {
return *$this-XorePwn( $_uu, $_xw ) ;* // obviously, that's not possible,
but a demo
}
}
?
So - is there a way to dynamically extend a class (not the traditionally
get-the-class,-clone-the-class-and-add-sugar-way) ?
I'd really like to hear some cool explanations - but, well, please don't
tell me that's not possible, because it's not possible.. ;)
So, cheers guys,
--
(c) *Kenan Sulayman*
*Freelance Designer and Programmer*
*Life's Live Poetry*
-- *Notice *--
The validity of none of any of the text in this mail is guaranteed. The
information in this message is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this message by anyone
else is unauthorized. If you are not the intended recipient, any
disclosure, copying or distribution of the message, or any action taken by
you in reliance on it, is prohibited and may be unlawful. If you have
received this message in error, please delete it and contact the sender
immediately. Thank you.
Re: [PHP-DEV] Runtime-Extension of Classes
On Thu, 2010-11-25 at 16:44 +0100, Kenan Sulayman wrote: So - is there a way to dynamically extend a class (not the traditionally get-the-class,-clone-the-class-and-add-sugar-way) ? After reading this three times i interpret it like I want to add stuff to the instance and no that is not possible (runkit doesn't count) by the definition of our class-based OO model. -- that should be -- mind the space. -- *Notice *-- The validity of none of any of the text in this mail is guaranteed. The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by [..] sorry. I just broke the rule as the addressee is the list, not me. Please get rid of this when sending the next mail to this list. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, Nov 25, 2010 at 16:28, Herman Radtke hermanrad...@gmail.com wrote: I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Developers can already wall themselves off now with the github mirror. No. People. Stop saying that. It simply isn't true. The 'github mirror' hasn't been active for 6months. It got killed because our box simply couldn't handle the job. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-Extension of Classes
Okay. :/ After all, thank you for the interjection of Runkit ^^ I think, I'll give it a try.. :) Thanks - and uhh - my signature really looks ugly in the mailing-list. Thanks for letting me know ;) Cheers, -- (c) *Kenan Sulayman* *Freelance Designer and Programmer* *Life's Live Poetry* 2010/11/25 Johannes Schlüter johan...@schlueters.de class-based OO
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans der...@php.net wrote: This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Four branches? Are you going to help? I'd to ask you to stop to say that in every 2nd person. What have you done lately to help anyway? Besides the controversial patch for type hinting? Right, there is no point to ask you that, so I remove this question. Please, just respect everyone giving us precious feedback as well as other developers. Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. That's a good theoretical point of view. And I maintain it doesn't work. It makes it for example very difficult to try out multiple new features at the same time; to say, to try to figure our whethr your app will still works. It's also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible (that's also why I am not a fan of DVCS, because it reduces that exposure drastically). You mean more than putting an extension in some random personal repository? Be serious please. github and bitbucket are the two best examples why these tools are fantastic ways to ease contributions, both for the developers and the contributors. The requests procedure is simply amazing, there are also tools to review manage external patches, with comments and history. That's simply impossible to do with svn. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 2010-11-25, Derick Rethans der...@php.net wrote: On Thu, 25 Nov 2010, Pierre Joye wrote: We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. Before even talking about git; the discussion should focus on whether we want DVCS. There are other things out there beside gits, which are not that difficult to use and provide just as much functionality. Actually, this is the right question... but there's another option. Offer PHP via as many VCS systems as possible. A number of Apache projects do this, and have ways to keep the various systems in sync. This would offer the most flexibility, as well as appease the largest number of developers. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. That's a pretty broad generalization, and one I've *never* heard voiced before. I've actually found exactly the opposite -- DVCS tends to be more democratic (developers can create and maintain features and share them easily), and less egocentric (DVCS developers are more willing to share and cherry-pick than in projects with centralized control). Can you please qualify the above statement. You want your stuff exposed to as many developers as possible instead of walled gardens. How is SVN not just another such walled garden? It might be easy enough to share, but discovery is a lot harder. Perhaps. But that's what mailing lists, issue trackers, and blogs are for. I've had very little issue with discovery, to be honest. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Nov 25, 2010, at 9:05 AM, Derick Rethans wrote: On Thu, 25 Nov 2010, Davey Shafik wrote: The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. While it's true the tools are not to blame, they're not HELPING the situation as much as some people seemed to think when the plan was thought out. Everything you say simply backs up my point that SVN is not the right tool for the model that seemed to be the goal. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Four branches? Are you going to help? I'm not sure why you seem to think this is so difficult. 5.2 would (ideally) have very little work going on. 5.3 would have somewhat more work, but is also closed to 5.4 so committing to two branches would be somewhat easier. 5.4 wouldn't be released till all features are complete, then it too moves to a bug fixes+security release and 5.2 gets sunsetted (this is why we need more reliable schedules). If we have releases every 6 months, or every 12 months (for example), it would mean each X.Y would last 12 or 24 months respectively. Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. That's a good theoretical point of view. And I maintain it doesn't work. It makes it for example very difficult to try out multiple new features at the same time; to say, to try to figure our whethr your app will still works. It's also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible (that's also why I am not a fan of DVCS, because it reduces that exposure drastically). Actually, it makes things easier, now you can simply do: svn co http://svn.php.net/r/php/php-src/branches/PHP_5_3 php-5.3 svn diff http://svn.php.net/r/php/php-src/branches/traits http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3 svn diff http://svn.php.net/r/php/php-src/branches/derick-typehints http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3 It means you get easy contiguous patches from any branch, over any number of commits (solving your issue above) And, as already pointed out, the collaboration possible through github is far more than we currently enjoy via SVN and ML/IRC today - but again, I don't want to propose git as a solution. As for talk of 6.0 as opposed to 5.4, nobody is going to risk putting their BC compatible features in a 6.0 release and then take 2 years to be adopted unless we force it (the committing to 6.0, not the adoption), when they can just create 5.5, 5.6, 5.14 and get it out before the stigma of the jump to 6.0 adoption. I don't have a solution for this that doesn't suck (forcing 6.0, or managing two branches, with all the same features, 5.x without the BC breaks, 6.0 with) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 2010-11-25, Andi Gutmans a...@zend.com wrote: -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, November 24, 2010 5:47 PM To: PHP internals Subject: [PHP-DEV] git anyone? We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I personally doubt moving will have a material positive impact on the project. I wouldn't particularly mind if all the issues were addressed but I wouldn't hold my breath that it will be game changing. It may be better to invest the effort elsewhere. I disagree here, actually. It's much easier to handle feature isolation using git, as you can do these in separate branches -- perhaps not even on the canonical repo! -- and later merge them in when they are ready. Additionally, keeping multiple branches up-to-date is much, much simpler. With ZF, I've found that merging in even months worth of changes from the ZF1 trunk to ZF2 master is often a matter of hours; with SVN, this process was so daunting, we simply wouldn't do it in favor of creating new branches and starting over. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Jani Taskinen [mailto:jani.taski...@iki.fi] Sent: Thursday, November 25, 2010 12:25 AM To: da...@php.net Cc: PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 Who says it has to be 5.4? People seem to be a bit fixated on the version there. Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. I agree and I don't think we're in as bad shape although there's some cleaning up that needs to be done. For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. I believe there's quite a bit more that we can do during the pre-beta phase in these areas to strengthen that and those changes with a combination of traits, some cleanup of deprecated e.g. safe_mode could warrant a major new version. If we do go down that route I would advocate calling it PHP 7 and not PHP 6, not because I like jumping ahead so far (I don't like I am sure most people here don't) but we don't want people to search for PHP 6 and find past information which is not relevant to this version we release. Then again I can live with it either way but we should be aware of the negative implications there could be. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. Yes, larger changes to the engine changed the major number. But all of them had a big effect. This is only performance. No functionality. 90% of the users won't notice it. Whereas everbody oticed the change from3 to 4 or the new object model in 5. Changing the major number has two big effects: a) marketing b) more fear for doing the upgrade. I value b) as the more relevant factor to monitor. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 15:11 +, Derick Rethans wrote: Yes, I also think trunk should be 5.4. It's not the most ideal thing though, but something we'll have to live with. It's going to be a lot less of a hassle than cherry picking trunk's features and graft them onto 5.3. Agreed. Cherry picking from trunk is no option. For being able to do this one either needs feature branches or some strict rules for commit message (for instance always refer to the relevant RFCs) so one can filter the commits properly. Changing to such a model doesn't belong in a discussion with 5.4 in the subject. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 6:11 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Jani Taskinen [mailto:jani.taski...@iki.fi] Sent: Thursday, November 25, 2010 12:25 AM To: da...@php.net Cc: PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 Who says it has to be 5.4? People seem to be a bit fixated on the version there. Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. I agree and I don't think we're in as bad shape although there's some cleaning up that needs to be done. It is not bad, it is only painful. I did the merges for 5.3.0-3 and I can tell you that SVN is simply broken for such things. I do it with git for many other projects and I never had real issues. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 9:20 AM, Johannes Schlüter wrote: On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. Yes, larger changes to the engine changed the major number. But all of them had a big effect. This is only performance. No functionality. 90% of the users won't notice it. Whereas everbody oticed the change from3 to 4 or the new object model in 5. Changing the major number has two big effects: a) marketing b) more fear for doing the upgrade. I value b) as the more relevant factor to monitor. Looking through trunk I think we are in pretty good shape. I don't think cherry-picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, Nov 25, 2010 at 5:54 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: It might be easy enough to share, but discovery is a lot harder. Perhaps. But that's what mailing lists, issue trackers, and blogs are for. I've had very little issue with discovery, to be honest. And www.php.net, that's exactly what is meant in the release management RFC, under the feature preview release. rmtools.php.net can also be easily adapted to fetch src from git and the build bots will work just fine as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Developers can already wall themselves off now with the github mirror. No. People. Stop saying that. It simply isn't true. The 'github mirror' hasn't been active for 6months. It got killed because our box simply couldn't handle the job. My mistake. The github mirror really isn't the point thought. The point is that anyone can use git-svn to make a git repo of PHP source and isolate themselves. -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
hi Rasmus, 2010/11/25 Rasmus Lerdorf ras...@lerdorf.com: On 11/25/10 9:20 AM, Johannes Schlüter wrote: On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. Yes, larger changes to the engine changed the major number. But all of them had a big effect. This is only performance. No functionality. 90% of the users won't notice it. Whereas everbody oticed the change from3 to 4 or the new object model in 5. Changing the major number has two big effects: a) marketing b) more fear for doing the upgrade. I value b) as the more relevant factor to monitor. Looking through trunk I think we are in pretty good shape. I don't think cherry-picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. Agreed, a php6 now just does not make sense, no matter from which point of view. I would not define 5.4 as being in a good shape but in a very promising shape to prepare a release. Removing the breakage, do some clear review of what we have (from a BC pov for one) and we could begin with a 5.4 release. However let get the RFC sorted out first before (it seems that we clearly have a consensus on most parts, time lines need to be adapted to avoid 5 releases at the same time :). Indeed, the type hint patch should be reverted as well, the sooner the better. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 2010-11-25, Herman Radtke hermanrad...@gmail.com wrote: Developers can already wall themselves off now with the github mirror. No. People. Stop saying that. It simply isn't true. The 'github mirror' hasn't been active for 6months. It got killed because our box simply couldn't handle the job. My mistake. The github mirror really isn't the point thought. The point is that anyone can use git-svn to make a git repo of PHP source and isolate themselves. Nope you cannot. We forbid total git-svn clones as they put too much traffic on the svn server. You can run a shallow clone, but either way you will have a hard time merging and using all the nice DVCS features together when you use git-svn. git-svn is more a local svn with local feature branches than a full blown git. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010 9:21 AM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP Internals Subject: RE: [PHP-DEV] Re: Hold off 5.4 On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. Yes, larger changes to the engine changed the major number. But all of them had a big effect. This is only performance. No functionality. 90% of the users won't notice it. Whereas everbody oticed the change from3 to 4 or the new object model in 5. Changing the major number has two big effects: a) marketing b) more fear for doing the upgrade. I value b) as the more relevant factor to monitor. I agree it is border line. I didn't say I feel strongly about it but I also wouldn't dismiss the changes we are making in PHP-next both from a core runtime point of view, backwards compatibility + new functionality as a minor version. As technologies mature new major versions are often a bit more balanced which makes sense given we have such a huge user base. This is no different in the Java world, C++ as it matured or some other technologies. From a core runtime point of view I think the changes are actually quite far reaching. I also believe there's more that we can do and want to try and do. From a BC point of view I do think it's an opportunity to clean up quite a bit. I am not an advocate of going crazy but I think we've already identified a few areas as a group that we feel comfortable with that strike a good balance between BC and helping move things forward. I think these are major version changes not minor version changes. From a functionality point of view I actually think there's some good functionality here: - Traits (I think this is major) - Some additional language improvements around array dereferencing, configurable mbstring support at runtime (we still need to do some work there), closure enhancements, ... - Some major and minor improvements in modules such as FastCGI, JSON, hashing, ... I think this is definitely more than minor version. I agree it may feel somewhat light as a major version but there is no such thing as a manor version :) In the spirit of release early and often I would actually gravitate towards the major version and start with clean slate although I also understand the other side of the world. In this scenario I would not use the excuse of a major version to go crazy though. Keep it sane and similar to what we're discussing now with maybe some additional engine improvements, additional cleanup and some extension work that can probably still be done. It has to be extremely finite (short list) and managed in a good release process. I do think if we continue to do major minor versions like we've done in the 5.x branch we will probably stay in the 5.x branch perpetually and it could be confusing to our users when they get major BC breaks and changes within the same major version. Andi
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 9:27 AM To: Johannes Schlüter Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 Looking through trunk I think we are in pretty good shape. I don't think cherry- picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. Btw, just to be clear I am also OK with this approach. I just wanted to make sure we consider the pros/cons of doing minor vs. major so we're all aligned re: the implications :) I would pass on any type hinting patch because there's no consensus and if we rip it out we are pretty much set to go (and I do not see a major negative implication of taking it out). Less is more IMO and it will enable us to get good functionality out sooner. We will probably make some more engine enhancements during pre-beta but can freeze at any point in time. Andi
Re: [PHP-DEV] Re: Hold off 5.4
Looking through trunk I think we are in pretty good shape. I don't think cherry-picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. -Rasmus I Second that. The 5.4 will be backwards compatible release to the 5.3 code as far as PHP applications are concerned. The only items that would be broken are deprecated features we may choose to remove like register_globals,magic_quotes_gpc,etc... Having this release out, to let people realize the performance benefits from core + apc bundling it offers would be supremely helpful to all users of PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
Hi, Completely different topic :) I've been looking a bit into performance around json encoding, hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled and often transmitted over the wire. I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Thanks, Andi
Re: [PHP-DEV] Re: Hold off 5.4
2010/11/25 Andi Gutmans a...@zend.com: -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 9:27 AM To: Johannes Schlüter Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 Looking through trunk I think we are in pretty good shape. I don't think cherry- picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. Btw, just to be clear I am also OK with this approach. I just wanted to make sure we consider the pros/cons of doing minor vs. major so we're all aligned re: the implications :) I would pass on any type hinting patch because there's no consensus and if we rip it out we are pretty much set to go (and I do not see a major negative implication of taking it out). Less is more IMO and it will enable us to get good functionality out sooner. We will probably make some more engine enhancements during pre-beta but can freeze at any point in time. Agreed here as well. I think we can begin with the release in January (I mean actually begin with the 1st test release). That lets us a couple of weeks (don't forget December has some family mandatory activities for most of us :) to actually get the RFC sorted out and review what we have. By review I mean to actually focus on evaluating trunk from a BC/QA/design point of view. I'm not saying it is badly designed or whatever else negative, but that most of us were busy with the current active branches and other bugs. I'm sure these 2-3 weeks more will benefit the php-next release and will make us feel much more confident about it, from day 1. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
As much as i might not have enough Karma to vote, being only involved in tests, but i think git would be a great fit. I agree with Phillip that we need to address the issues mentioned before if we want to move over, but our community includes guys like Travis Swicegood, who quite literally wrote the book on Git, i'm sure we can count on his help to aid us in sorting those out. I'm a +1 if we have also docs and usage examples to help the learning curve of git beginners. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
I think there is much to gain by improving the serialization speed in PHP. It is used everywhere from caches like memcache, to sessions or manual data input into DB. I would say that there are very few non-trivial apps that would not benefit from a more compact and faster serializer. In our specific work-use-case switching to igbinary improved the speed of the overall page generation by 2-3%. On Thu, Nov 25, 2010 at 12:47 PM, Andi Gutmans a...@zend.com wrote: Hi, Completely different topic :) I've been looking a bit into performance around json encoding, hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled and often transmitted over the wire. I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: This is no different in the Java world, C++ as it matured or some other technologies. Java is currently at 1.6. (and 6 in Marketing) :-) C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting for C++0x, whatever the actual name will be. No good examples ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 9:44 AM, Ilia Alshanetsky wrote: Looking through trunk I think we are in pretty good shape. I don't think cherry-picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. -Rasmus I Second that. The 5.4 will be backwards compatible release to the 5.3 code as far as PHP applications are concerned. The only items that would be broken are deprecated features we may choose to remove like register_globals,magic_quotes_gpc,etc... Having this release out, to let people realize the performance benefits from core + apc bundling it offers would be supremely helpful to all users of PHP. We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 10:26 AM To: Ilia Alshanetsky Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 10:26 AM To: Ilia Alshanetsky Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). What do you think about a path argument? Returning something like zend_file_handle with some more meta info. Doing so will let us pass all the way down to the actual file API system call without having to duplicate opearions (stat, perms, etc.) as each ops will simply set the member accordingly. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 10:33 AM, Andi Gutmans wrote: -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 10:26 AM To: Ilia Alshanetsky Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). I'm not too worried about the performance impact here. Functions that need these non-null strings need them because they are about to access the file system in some way. The time it takes to check for nulls compared to the file system access time is so small that I think we can safely ignore performance issues. -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 10:43 AM, Pierre Joye wrote: On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 10:26 AM To: Ilia Alshanetsky Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). What do you think about a path argument? Returning something like zend_file_handle with some more meta info. Doing so will let us pass all the way down to the actual file API system call without having to duplicate opearions (stat, perms, etc.) as each ops will simply set the member accordingly. It wouldn't work in place of the non-null type. There are a number of places where we are passing just filenames and it is up to the lower level functions to figure out what to do with these and also places where we just pass fragments or we pass stuff into things like the session extension or database LOB calls. So, even if we did come up with a zend_file_handle type, we would still need the non-null type for all the places where we don't have a complete path. Also, I am curious where you think we have duplicate operations like that? -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
-Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 10:46 AM To: Andi Gutmans Cc: Ilia Alshanetsky; Johannes Schlüter; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). I'm not too worried about the performance impact here. Functions that need these non-null strings need them because they are about to access the file system in some way. The time it takes to check for nulls compared to the file system access time is so small that I think we can safely ignore performance issues. Yes I thought about that too after I sent the email :) It is negligible compared to the expensive filesystem operation. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 7:52 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 11/25/10 10:43 AM, Pierre Joye wrote: On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Thursday, November 25, 2010 10:26 AM To: Ilia Alshanetsky Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals Subject: Re: [PHP-DEV] Re: Hold off 5.4 We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). What do you think about a path argument? Returning something like zend_file_handle with some more meta info. Doing so will let us pass all the way down to the actual file API system call without having to duplicate opearions (stat, perms, etc.) as each ops will simply set the member accordingly. It wouldn't work in place of the non-null type. There are a number of places where we are passing just filenames and it is up to the lower level functions to figure out what to do with these and also places where we just pass fragments or we pass stuff into things like the session extension or database LOB calls. So, even if we did come up with a zend_file_handle type, we would still need the non-null type for all the places where we don't have a complete path. Also, I am curious where you think we have duplicate operations like that? I noticed it where functions accepts a path, do some checks (exists, writable, etc.), resolves paths, etc. and then similar ops are done again in a couple of places before we call the low level functions, like in stream, tsrm for example, or extension using other extension's streams. The idea is that file.absolute_path, file.original_path, or file.resolved_path (example member names) will be passed to the low level APIs, where each of them have been checked for NULL as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 11:01 AM, Pierre Joye wrote: I noticed it where functions accepts a path, do some checks (exists, writable, etc.), resolves paths, etc. and then similar ops are done again in a couple of places before we call the low level functions, like in stream, tsrm for example, or extension using other extension's streams. The idea is that file.absolute_path, file.original_path, or file.resolved_path (example member names) will be passed to the low level APIs, where each of them have been checked for NULL as well. Do you have an example? Also, these checks are going to hit the stat cache, so I don't think there is much to gain here. -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 10:25 -0800, Rasmus Lerdorf wrote: We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. Recently there was an off-list discussion about adding support for accepting non-empty strings only via zend_parse_parameters (zpp). There I raised the concern that we shouldn't add too many special validations for two main reasons: a) The more options zpp has the harder it is to use/read/maintain b) Errors from zpp usually are typically caused by program errors which in other languages for instance might be detected by a compiler not for being bad values as such errors might require different handling by the user. The null-byte thing is not only good for file operations but also for ereg and other places. But we should be sure about the error semantics caused. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Performance of buffer based functionality (JSON, AES, serialize())
Hi, I think it would, a lot of sites/apps nowadays rely a lot on JSON encoding/decoding, plus a lot of technologies are relying on serialization/json encoding (Memcached, Redis, to name a few) at the PHP level, which can be a really big performance eater if you use it a lot. On the other hand, it's not too difficult to get IGBinary setup as serializer instead of the default one, and it does some pretty good improvement. Ever considered making it a part of PHP? What would be the implication (as I'm not too familiar with all the internals of PHP besides extensions...)? Michel Bartz Lead Developer Manwin Canada Skype: michel.php -Original Message- From: Andi Gutmans [mailto:a...@zend.com] Sent: Thursday, November 25, 2010 12:47 PM To: internals@lists.php.net Subject: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize()) Hi, Completely different topic :) I've been looking a bit into performance around json encoding, hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled and often transmitted over the wire. I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Thanks, Andi This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
hi, For the record here, igbinary is a very good example of such optimization: http://opensource.dynamoid.com/ On Thu, Nov 25, 2010 at 6:47 PM, Andi Gutmans a...@zend.com wrote: Hi, Completely different topic :) I've been looking a bit into performance around json encoding, hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled and often transmitted over the wire. I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Thanks, Andi -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote: For the record here, igbinary is a very good example of such optimization: http://opensource.dynamoid.com/ igbinary is a nice extension indeed. However, for those of us who have environments which include multiple programming languages, custom serializations become a PITA. As such, we generally go with something more portable such as Avro or straight JSON. Awhile back, I had done some work rewriting the JSON serialization functions to use the fast (and BSD licensed) yajl JSON parser (https://github.com/lloyd/yajl). Initial benchmarks showed a 4-7% performance improvement in serialization/deserialization. I'll see if I can dig it up--hopefully it's not on my dead computer. -- Jonah H. Harris Blog: http://www.oracle-internals.com/
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris jonah.har...@gmail.com wrote: On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote: For the record here, igbinary is a very good example of such optimization: http://opensource.dynamoid.com/ igbinary is a nice extension indeed. However, for those of us who have environments which include multiple programming languages, custom serializations become a PITA. As such, we generally go with something more portable such as Avro or straight JSON. Awhile back, I had done some work rewriting the JSON serialization functions to use the fast (and BSD licensed) yajl JSON parser (https://github.com/lloyd/yajl). Initial benchmarks showed a 4-7% performance improvement in serialization/deserialization. Good point indeed. That makes me think about bson (http://bsonspec.org/), which is used by mongodb for example. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposed - Integrated inner iterator support for Iterator classes
Hi everyone,
I've been taking another look at iterators lately, and compiled trunk and
started experimenting with traits. I also looked at an old mail from Marcus
regarding iterator_apply, and find myself wondering why there isn't just an
'apply' method as part of the Iterator hierarchy itself.
Although PHP had support for the pseudo-type callback when the Iterator
interface was introduced, I'm not sure why an 'apply' function would have
been omitted from the original Iterator interface. Clearly with
iterator_apply out there, there is no functional gain by adding a method
into the Iterator hierarchy, however I think it would be more cohesive with
the OO paradigm the Iterator hierachy presents .. there is already
array_walk and friends for the global function gang :) And now with
closures the idea of an 'apply' method is even more enticing .. yes I'm
thinking of Javascript code like JQuery's each() ...
I can tell why it wouldn't have been added after the original interface was
in the wild though, because changing the interface would break tons of
client code. However a second interface could be added and all client code
would continue to function
interface InnerIterator
{
function apply($mCallback [, mixed $...]);
}
Rather than extend Iterator, InnerIterator should be left independent so it
can be incorporated into implementors of OuterIterator (see below). Then
concrete Iterator(s) could implement this new interface as well
class ArrayIterator implements Iterator, InnerIterator { … }
I'm not sure what the best implementation at the engine level would be, but
with the advent of traits that would clearly be one option, a simple
implementation could be something like
trait InnerIteratorImpl
{
public function apply($mCallback)
{
$aArgs = func_get_args();
array_shift($aArgs);
$aCallbackArgs = array_merge(array($this), $aArgs);
return iterator_apply($this, $mCallback, $aCallbackArgs);
}
}
Then the ArrayIterator definition could become
class ArrayIterator implements Iterator, InnerIterator
{
use InnerIteratorImpl;
...
}
I hardly doubt this is necessary inside the engine, as I'm sure there can be
a common C function which is used to implement the interface, but that would
be for more educated people to decide.
Classes which implement IteratorAggregate (ArrayObject for example) would
then return implementors of InnerIterator, which still implement Iterator as
they originally did. Classes which implement OuterIterator could now also
implement InnerIterator as well, and the 'apply' method in that case can
simply delegate to the wrapped Iterator as they currently do for implemented
Iterator methods.
class CachingIterator implements OuterIterator, InnerIterator
{
public function apply($mCallback)
{
return $this-getInnerIterator()-apply(func_get_args());
}
}
A quick example from userspace with the addition
$oArrayObj = new ArrayObject(array(5, 4, 3, 2, 1));
$oArrayObj-getIterator()-apply(function(Iterator $oIt) {
var_dump($oIt-current());
return true;
});
At the end of the day it's just syntactic sugar since iterator_apply is
there, but in my book it would be welcome sugar ;) I would also argue that
even with traits, implementing this notion in userspace is slower (needless
conversion) and messy, imagine a subclass of ArryObject for example that
implements InnerIterator, inside of getIterator, it has to convert the
ArrayIterator to a new userspace class InnerArrayIterator or some such,
which implements InnerIterator, before returning it.
Your thoughts appreciated!
-nathan
RE: [PHP-DEV] Re: Hold off 5.4
I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. 2. Maybe it's time to break the notion that a major number change means major breakage. Sometimes (like in Google Chrome), a major version can bring nothing but a few new features and significantly improve performance, without any additional pain. Not saying we should go to the extreme of releasing a major version every other week, but once a year or once every 18 months is a very reasonable frequency. Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). My 2c. Zeev -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010 7:55 PM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP Internals Subject: RE: [PHP-DEV] Re: Hold off 5.4 On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: This is no different in the Java world, C++ as it matured or some other technologies. Java is currently at 1.6. (and 6 in Marketing) :-) C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting for C++0x, whatever the actual name will be. No good examples ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 16:56, Zeev Suraski z...@zend.com wrote: Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). Perl? Oh, PHP. -- /Daniel P. Brown http://www.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Is it just unusually cold weather for this time of year or did the hell just freeze over? :-o Couldn't agree more on both points and I had the same thoughts about getting stuck with 5.x releases forever. And not getting any release out soon from trunk if this thread drags on too long. Maybe even skip 6 like Andi proposed and declare that from now even major versions are never released. Only prime numbers count. 7 is a prime number and it's the lucky one too. ;) --Jani p.s. Somehow this reminds me of one particular discussion in around 2001 about the versioning scheme.. :D 25.11.2010 23:56, Zeev Suraski wrote: I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. 2. Maybe it's time to break the notion that a major number change means major breakage. Sometimes (like in Google Chrome), a major version can bring nothing but a few new features and significantly improve performance, without any additional pain. Not saying we should go to the extreme of releasing a major version every other week, but once a year or once every 18 months is a very reasonable frequency. Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). My 2c. Zeev -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010 7:55 PM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP Internals Subject: RE: [PHP-DEV] Re: Hold off 5.4 On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: This is no different in the Java world, C++ as it matured or some other technologies. Java is currently at 1.6. (and 6 in Marketing) :-) C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting for C++0x, whatever the actual name will be. No good examples ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski z...@zend.com wrote: I think that skipping to a major version is a good idea. It is appealing but not a good idea. I think it is better to get 5.4 with the features we like in it and then consider a major version. There are quite a few things that we could add or changethat would justify a major version (without opening one of our pandora's boxes right now :). As of versioning scheme, yes, a clear and documented one is the way. Anything we can add to the RFC to clarify this would be welcome. Maybe start a new thread, it is getting hard to follow each topic. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
Just read over the BSON spec, looks fairly interesting, the only bit that appears to be missing for PHP purposes is object support. We would need to introduce custom type on top of standard BSON. However from compactness and consistency standpoint it looks fairly appealing. On Thu, Nov 25, 2010 at 2:51 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris jonah.har...@gmail.com wrote: On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote: For the record here, igbinary is a very good example of such optimization: http://opensource.dynamoid.com/ igbinary is a nice extension indeed. However, for those of us who have environments which include multiple programming languages, custom serializations become a PITA. As such, we generally go with something more portable such as Avro or straight JSON. Awhile back, I had done some work rewriting the JSON serialization functions to use the fast (and BSD licensed) yajl JSON parser (https://github.com/lloyd/yajl). Initial benchmarks showed a 4-7% performance improvement in serialization/deserialization. Good point indeed. That makes me think about bson (http://bsonspec.org/), which is used by mongodb for example. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
I don't think the version # makes that much of a difference, but rather what is in it. That said, people have made a good point that jumping to something like 7, would allow us to skip the baggage associated with PHP6, which seems like a fairly compelling argument to me. On Thu, Nov 25, 2010 at 6:01 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski z...@zend.com wrote: I think that skipping to a major version is a good idea. It is appealing but not a good idea. I think it is better to get 5.4 with the features we like in it and then consider a major version. There are quite a few things that we could add or changethat would justify a major version (without opening one of our pandora's boxes right now :). As of versioning scheme, yes, a clear and documented one is the way. Anything we can add to the RFC to clarify this would be welcome. Maybe start a new thread, it is getting hard to follow each topic. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
That can always be done later. Even if I don't think users care much about 6 or 7 being the version for the next major release. However for what I can read or hear, they care about traits and many of the points described in the RFC. Maybe we could focus on getting the RFC sorted out and figure out what can or should remain in a 5.4 release. We are almost ready to go with it, a matter of weeks. I fear that a major release is something we are not able to deal with right now. Then we can begin with the next major (call it php 11 if we like to, does not really matter ;) version. There are still plenty of work for it (we all have in mind at least one thing). On Fri, Nov 26, 2010 at 1:19 AM, Ilia Alshanetsky i...@prohost.org wrote: I don't think the version # makes that much of a difference, but rather what is in it. That said, people have made a good point that jumping to something like 7, would allow us to skip the baggage associated with PHP6, which seems like a fairly compelling argument to me. On Thu, Nov 25, 2010 at 6:01 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski z...@zend.com wrote: I think that skipping to a major version is a good idea. It is appealing but not a good idea. I think it is better to get 5.4 with the features we like in it and then consider a major version. There are quite a few things that we could add or changethat would justify a major version (without opening one of our pandora's boxes right now :). As of versioning scheme, yes, a clear and documented one is the way. Anything we can add to the RFC to clarify this would be welcome. Maybe start a new thread, it is getting hard to follow each topic. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Hi 2010/11/25 Zeev Suraski z...@zend.com: I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. I also think that its appealing to skip to version 6 to break that spell once and for all. While still having 5.4, with backported enhancements and features like Traits. Which also leaves us to the breakage point, allowing us to get rid of magic_quotes in trunk while its kept in 5.4. 2. Maybe it's time to break the notion that a major number change means major breakage. Sometimes (like in Google Chrome), a major version can bring nothing but a few new features and significantly improve performance, without any additional pain. Not saying we should go to the extreme of releasing a major version every other week, but once a year or once every 18 months is a very reasonable frequency. Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). Although I don't feel strong about versioning either, but then I don't think it makes much sense to skip version 6 as suggested. 5.x is a major revision of PHP that we all like, but I won't want to be stuck in it forever either. Lets forget about the past PHP6 and make the present PHP6 happen instead. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
