On Sun, May 18, 2014 at 1:34 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> You keep talking about side effects of the patch.
No, what I have to keep saying, because this argument keeps coming, is
that the ability to store >2GB string is a side effect and not a goal
of this patch.
> It is these side
> effects that we have a problem with. We need a version of the patch that
> doesn't have all these undesired side effects.
The only one, and it is disputable, is the memory usage, which is
around 4% under real world usage (WP, Symfony, Drupal, and some other
apps). It even performs better in many common situations.
> You put the patch as it stands up for a vote and it is this patch we
> have to vote on which is why I am voting no on it. It isn't some future
> version with some unknown number of side effects removed.
I am not sure how to formulate it in a better way but let me try again.
- 64bit patch has been worked on and stabilized since months
- It is continuously tested using master, 5.5 and 5.6, using our full
tests suite (which is much more than just running phpt in cli if you
remember)
- the patch is stable
Given these points, and as it is the case with every new
features/addition/improvements we have made, tweaks, optimization,
etc. will happen after it gets approved and applied. Stability and
correctness have the priority.
Asking to take care of phpng was hardly possible given its sudden
public availability. However, we know that phpng can bring PHP a lot
and that is why we gave the option to merge the 64bit patch to phpng,
once it is gets somehow usable in common situations (estimation: 1-2
months if not critical bugs exist in common extensions, but can't test
them in a good way as of now).
I will post a mail about what we plan to do and how, this pretty much
matches what Nikita said and what I have been said since the very day
after we proposed the 64 bit patch again. Most likely tonight or
tomorrow morning.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org