On Tue, May 6, 2014 at 2:20 AM, Pierre Joye <[email protected]> wrote:
It is an awesome step moving forward, thanks to everyone involved in
> this work! I will see how fast we can integrate this branch in our
> tests.
>
>
Note, that we even didn't try to run it on Windows.
So it must be some problems.
>
> > Please try the refactored PHP engine and provide feedback re:
> performance,
> > memory usage and any issues that come up. You may find it in *phpng*
> branch
> > at *php.net <http://php.net>*. Some instructions may be
> > found at
> > *http://wiki.php.net/phpng
> > <http://wiki.php.net/phpng>*. As mentioned,
> > there are some missing
> > extensions so not everything will run.
>
> Could you move these pages (this one and the internal one) either to
> /draft or /rfc please? the latter makes more sense
>
> However I suppose basic windows tests are missing, as well as TS
> sapis, right? Is it at least supposed to work in TS mode, by design?
> Or should we expect some major issues?
>
ZTS wasn't in our priority list, but Nikita made it more or less work.
> > I would like to say many thanks to Xinchen and Nikita who made
> significant
> > part of presented work.
> >
> > I think that this engine can make the new major version of PHP we’re
> > talking about a lot more interesting.
>
> Do I understand correctly that you target php 6 for these changes, right?
>
The next major release - 6 or 7, of course, if we port all extensions and
solve all problems.
> 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.
Anyway, I think 64-bit integer support on Windows64 makes full sense and
it's possible to add it into "phpng" right now.
I'm not so sure about size_t string length.
>
> That being said, I am not sure what requires less effort but I do not
> feel comfortable to scratch the 64bit branch and begins from almost
> zero.
>
> There is something that we have to improve, drastically,
> communication. Such major changes, developed (and still being worked
> on) should pop up in the list and in the radar of other developers
> much earlier in the process. For two critical reasons:
>
> 1. Avoid work conflicts, be for similar features/changes or other
> areas being deadly affected by such changes
> 2. Increase visibility, feedback and cooperations. The earlier other
> developers are involved the better it is to get more people involved
> in the engine development and maintenance.
>
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 :)
> 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.
Anyway, I'm open to discussions, if they won't take too mach time.
Thanks. Dmitry.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>