Hi
2010/11/25 Zeev Suraski :
> 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/
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
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:
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
On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski 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 o
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
On Thu, Nov 25, 2010 at 16:56, Zeev Suraski 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
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 rec
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.
On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris wrote:
> On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye 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 w
On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye 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,
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 wrote:
> Hi,
>
> Completely different topic :)
>
> I've been looking a bit into performance around json encoding,
> hashing+encryption (a
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,
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_param
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 extensi
On Thu, Nov 25, 2010 at 7:52 PM, Rasmus Lerdorf wrote:
> On 11/25/10 10:43 AM, Pierre Joye wrote:
>> On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Thursday, November 25, 2010 10:26 AM
To:
> -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 ski
On 11/25/10 10:43 AM, Pierre Joye wrote:
> On Thu, Nov 25, 2010 at 7:33 PM, 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
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: [P
On Thu, Nov 25, 2010 at 7:33 PM, 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
>> Sub
> -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 n
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 o
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 n
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 specif
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 t
2010/11/25 Andi Gutmans :
>> -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
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
s
> 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 P
> -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
> -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 wrot
On 2010-11-25, Herman Radtke 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.
>
>
hi Rasmus,
2010/11/25 Rasmus Lerdorf :
> 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
>>> ve
>> 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 th
On Thu, Nov 25, 2010 at 5:54 PM, Matthew Weier O'Phinney
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 ex
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 forem
On Thu, Nov 25, 2010 at 6:11 PM, Andi Gutmans 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
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.
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 chang
> -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.
>
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, subve
On 2010-11-25, 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
> > develop
On 2010-11-25, Andi Gutmans 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 oppo
On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans 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).
>
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
On Thu, Nov 25, 2010 at 16:28, Herman Radtke 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.
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
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
>> >> 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
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 wo
On Thu, 25 Nov 2010, Ferenc Kovacs wrote:
> On Thu, Nov 25, 2010 at 3:26 PM, Lester Caine 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.
>
On Thu, 25 Nov 2010, Gustavo Lopes wrote:
> On Thu, 25 Nov 2010 14:05:43 -, 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
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
On Thu, 25 Nov 2010 14:05:43 -, 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
On Thu, Nov 25, 2010 at 3:26 PM, Lester Caine 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 part
On 25 November 2010 07:16, Patrick ALLAERT 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 I
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 gi
On 24 November 2010 18:03, Nathan Nobbe wrote:
> Ummm... never mind!
>
> Sorry for the noise!
>
> -nathan
>
> On Wed, Nov 24, 2010 at 11:00 AM, Nathan Nobbe wrote:
>
>> Hi all,
>>
>> I had a thought this morning and would like some feedback. Don't you think
>> it would make sense to allow the cal
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 a
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 sor
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, Jam
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 jus
On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:
> 2010/11/25 Jani Taskinen :
>> 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
On 25/11/10 12:22, Pierre Joye wrote:
On Thu, Nov 25, 2010 at 12:47 PM, Lester Caine 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 broke
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
On Thu, Nov 25, 2010 at 12:47 PM, Lester Caine 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 mon
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 bef
2010/11/25 Jani Taskinen :
> 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
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 featu
On 2010-11-23, Felipe Pena 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 alway
On 2010-11-23, Felipe Pena 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 be
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 Develo
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 Eclip
On 25/11/10 07:41, Lester Caine wrote:
Patrick ALLAERT wrote:
2010/11/25 Lester Caine:
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
worki
GIT is realy nice!
git merging magic!
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 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 ga
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
On 2010-11-25, 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
hi Andi,
On Thu, Nov 25, 2010 at 7:42 AM, Andi Gutmans 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
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
80 matches
Mail list logo
