On Tue, May 6, 2014 at 8:19 AM, Pierre Joye <[email protected]> wrote:
> On Tue, May 6, 2014 at 1:44 AM, Dmitry Stogov <[email protected]> wrote:
>
> > ZTS wasn't in our priority list, but Nikita made it more or less work.
>
> Why do I have a deja vu feeling? ;)
>
I really, don't see a lot of sense in using ZTS and didn't like to spend
our time.
> >> Also one thing is totally missing, and is also caused by something
> >> that becomes a common case, the 64bit support as it should be has been
> >> totally ignored. That makes Anatol work to keep the 64bit branch
> >> almost useless. My take on it is that we should either:
> >>
> >>
> >> - move your patch to this branch and then merge to master
> >> - merge the 64bit branche then this patch
> >
> >
> > I afraid both ways aren't going to be simple.
>
> Rght, but again, I really do not feel comfortable to ask Anatal or my
> team to redo all the work. This would be very bad.
>
I see your point. Please, look from mine.
Just compare the sizes of diffs between branches.
We won't be able to care about unstable development branches...
We may help, with reimplementation of int64 patch, but actually we come to
ask help ourselves.
I hope we will found some compromise. It can't be a problem if our goals
are not opposite :)
> > Anyway, I think 64-bit integer support on Windows64 makes full sense and
> > it's possible to add it into "phpng" right now.
>
> Again, it is by far not only a windows change, even if Windows is the
> platform with the most visible change from a user point of view.
>
OK. Win64 is enough for this patch. I wouldn't care about others, because I
even don't know the names.
> > I'm not so sure about size_t string length.
>
> It is hardly imaginable to release php 6 with strings length still
> using integer. The memory consumption has been shown to be minimal
> during the discussions about the 64bit support. Or did I miss some
> important new information?
>
I wouldn't mix size_t string length with 64-bit support. These are two
independent changes.
int64 would make 64-bit PHP version behave more or less consistent with
minimal cost.
size_t string length will increase memory consumption and memory traffic
for the cases that no one web application will use (2GB strings).
I'm trying to save (or even improve) memory consumption, because I know how
it may affect performance because of CPU cache misses.
Lets apply the first part first.
Sorry, I already said my opinion about development.
Thanks. Dmitry.
> > I understand your opinion, but when we started this project we didn't
> know
> > if we will get any useful results at all.
> > You know, I can't ask everyone in PHP community to freeze development and
> > wait while we are thinking :)
>
> No, but it is possible to get a branch and work on it, sync it with
> the other relevant branch. That is what we have done for the 64bit
> branch, providing updated builds and tests results while working on
> it. Everyone can test it or contribute. This is the way to do such
> things from a technical point of view. It is also the way to do it
> from a cooperation point of view, for the reasons I gave earlier.
>
>
> >> I am not sure how to change that or make developers being more open
> >> and stopped hidden developments. Any ideas or thoughts on this topic
> >> are welcome. It is critical and vital for php, a must do.
> >
> >
> > I don't see problem in hidden development. The formed ideas come as RFC
> with
> > patches.
>
> Well, I do when it comes to such massive changes, no matter how
> positive they are. It is all about being open and transparent. Early
> participation eases the understanding of the changes, design or
> debugging of the new features or changes. This reduces the bus factor
> when it comes to maintain it and we both know that this has been an
> issue for too long for everything around the engine area.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>