We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.
Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.
The diff is easy enough to grab:
git clone https://github.com/php-memcached-dev/php-memcached.git
cd php-memcached
git checkout php7
git diff master php7
It looks like this:
https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments. But is there
something more suited for this out there?
-Rasmus
Hi Rasmus,
Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would never be
usable in earlier versions once finished the update.
Maybe it would be interesting to have samples of before/after (like you
did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.
Regards,
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.The diff is easy enough to grab:
git clone https://github.com/php-memcached-dev/php-memcached.git
cd php-memcached
git checkout php7
git diff master php7It looks like this:
https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments. But is there
something more suited for this out there?-Rasmus
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Hi Rasmus,
Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be minimized by providing possible alternate implementations that could work both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would never be usable in earlier versions once finished the update.Maybe it would be interesting to have samples of before/after (like you did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.
That is one of the reasons an annotated diff would be good. All the changes in the diff aren't strictly needed. I didn't need to change from "s" to "S" in ZPP and the accompanying change to zend_string for example, but I find the new API cleaner and less error-prone.
-Rasmus
On Feb 5, 2015, at 17:41, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:Hi Rasmus,
Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would never be
usable in earlier versions once finished the update.Maybe it would be interesting to have samples of before/after (like you
did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.That is one of the reasons an annotated diff would be good. All the
changes in the diff aren't strictly needed. I didn't need to change from
"s" to "S" in ZPP and the accompanying change to zend_string for example,
but I find the new API cleaner and less error-prone.
What do you think about the creation of an example extension covering
almost everything one would do in an extension?
The class, methods or functions do not have to be useful but to have simple
clear examples to display the differences with extensive comments.
Doing so has the big advantage of being self contained and anyone can
contribute easily. It is also easier for someone to actually play with it
than with a diff.
I was thinking about that for a workshop I have to give in April.
Cheers
Pierre
De : Pierre Joye [mailto:pierre.php@gmail.com]
What do you think about the creation of an example extension covering
almost everything one would do in an extension?The class, methods or functions do not have to be useful but to have simple
clear examples to display the differences with extensive comments.Doing so has the big advantage of being self contained and anyone can
contribute easily. It is also easier for someone to actually play with it
than with a diff.
Maybe php-ext-gen can be useful here. It is a PHP extension generator I just wrote, with the objective to avoid splitting extension source trees to two independent branches, as differences between PHP 5 & 7 are beyond what macros can do. The other objective is to make it easier to write a typical 'bridge' extension without knowing much to the PHP API (without manipulating any zval). It could be an ideal environment for an example extension.
The current version already abstracts and generates code for argument parsing, return types, ini settings, resources, functions, constants. The source for this is a Yaml or Json synthetic description and C code reduced to the bare minimum.
It is based on pluggable generators, the primary scope being PHP5, PHP7, and HHVM. Currently, the only implemented generator is PHP 5, but PHP 7 will be easy to implement (it is based on twig templates).
The project is at https://github.com/flaupretre/php-ext-gen. Look in the examples subdir, the wiki, and tell me what you think.
Cheers
François
De : Pierre Joye [mailto:pierre.php@gmail.com]
What do you think about the creation of an example extension covering
almost everything one would do in an extension?The class, methods or functions do not have to be useful but to have simple
clear examples to display the differences with extensive comments.Doing so has the big advantage of being self contained and anyone can
contribute easily. It is also easier for someone to actually play with it
than with a diff.Maybe php-ext-gen can be useful here. It is a PHP extension generator I just wrote, with the objective to avoid splitting extension source trees to two independent branches, as differences between PHP 5 & 7 are beyond what macros can do. The other objective is to make it easier to write a typical 'bridge' extension without knowing much to the PHP API (without manipulating any zval). It could be an ideal environment for an example extension.
The current version already abstracts and generates code for argument parsing, return types, ini settings, resources, functions, constants. The source for this is a Yaml or Json synthetic description and C code reduced to the bare minimum.
It is based on pluggable generators, the primary scope being PHP5, PHP7, and HHVM. Currently, the only implemented generator is PHP 5, but PHP 7 will be easy to implement (it is based on twig templates).
The project is at https://github.com/flaupretre/php-ext-gen. Look in the examples subdir, the wiki, and tell me what you think.
Not sure it will help. It is really about showing cases for deref,
duplicate, convert, iterate, etc. The zpp, return values or
functions/class/methods declaration are really the easy part here.
--
Pierre
@pierrejoye | http://www.libgd.org
De : Pierre Joye [mailto:pierre.php@gmail.com]
Not sure it will help. It is really about showing cases for deref,
duplicate, convert, iterate, etc. The zpp, return values or
functions/class/methods declaration are really the easy part here.
I understand. I thought it would be a nice way to enhance the abstraction layer php-ext-gen provides, as I am missing use cases. Generating glue code is just one of the project objectives. The second one is to provide an abstraction layer allowing to duplicate as few code as possible when migrating an extension to PHP 7 (HHVM is also in scope).
I already fully abstract resources, so that user code doesn't have to deal, for instance, with zend_resource structs. I also provide an API for persistent resources, which Zend does not provide. That's just an example. It can be done for many other areas.
But, if you don't want to participate, I'll integrate that myself using your examples.
Just a question : for your demo extension, would you write two branches or a single one with #ifdef directives ?
Cheers
François
De : Pierre Joye [mailto:pierre.php@gmail.com]
Not sure it will help. It is really about showing cases for deref,
duplicate, convert, iterate, etc. The zpp, return values or
functions/class/methods declaration are really the easy part here.I understand. I thought it would be a nice way to enhance the abstraction
layer php-ext-gen provides, as I am missing use cases. Generating glue code
is just one of the project objectives. The second one is to provide an
abstraction layer allowing to duplicate as few code as possible when
migrating an extension to PHP 7 (HHVM is also in scope).I already fully abstract resources, so that user code doesn't have to
deal, for instance, with zend_resource structs. I also provide an API for
persistent resources, which Zend does not provide. That's just an example.
It can be done for many other areas.But, if you don't want to participate, I'll integrate that myself using
your examples.
It is more a time issue and a non believer in too much generation of codes.
Just a question : for your demo extension, would you write two branches
or a single one with #ifdef directives ?
I ported one (not oss sadly) and I end up with separate files. One for 5.x,
7.x and common helpers.
Cheers
François
On Thu, Feb 5, 2015 at 10:41 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would never be
usable in earlier versions once finished the update.
Hi,
I have create a header that does it ( see
https://github.com/bukka/phpc/blob/master/phpc.h ). There are still quite a
few bits that need to be added and tidied up but it already suppors most
cases that I will need in my extension.
The header probably doesn't show much (and might look a bit scary ... :) )
so I have created a testing ext that uses it. You can see the result here:
https://github.com/bukka/php-extest/blob/master/extest_compat.c
As you can see there isn't a single ifdef and it compiles and works (test
passes) for PHP 7 and 5 (tested on 5.6 but should be fine for 5.2+). It
means that it won't require any changes in PECL.
There isn't much documentation as yet because I'm still working on it. But
I plan to add it later.
Any comments or patches are welcome!
Cheers
Jakub
https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments. But is there
something more suited for this out there?
A few extra notes on the commit would have helped. And breaking down
some of the bigger changes to individual 'reasons'.
But http://hg.lsces.org.uk/hg/php-memcached/rev/c3c53d0ef330 is just a
little easier to read and I can scroll through the changes. It DOES need
a good set of examples to work from, and the assortment of changes to
imagick are more difficult to understand.
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Rasmus,
Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.The diff is easy enough to grab:
git clone https://github.com/php-memcached-dev/php-memcached.git
cd php-memcached
git checkout php7
git diff master php7It looks like this:
It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Sent from my iPhone
Hi Rasmus,
Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.The diff is easy enough to grab:
git clone https://github.com/php-memcached-dev/php-memcached.git
cd php-memcached
git checkout php7
git diff master php7It looks like this:
It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.
nice，thanks
btw did you bench your optimization on file handler against Wordpress?
Thanks
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Xinchen,
Hi Rasmus,
On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.The diff is easy enough to grab:
git clone https://github.com/php-memcached-dev/php-memcached.git
cd php-memcached
git checkout php7
git diff master php7It looks like this:
It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.nice，thanks
btw did you bench your optimization on file handler against Wordpress?
No I don't, but I have some numbers.
https://github.com/php/php-src/pull/1016
I've tried to get some benchmarks. It seems current system is too fast to
get obvious performance difference.
Test command: ab -c 7 -n 500000 http://localhost:8888/session.php
Test script:
<?php
ini_set('session.save_path', '/home/tmp');
ini_set('session.lazy_write', 1); // Change mode here
ini_set('session.use_strict_mode', 0);
session_id('testid');
session_start(['read_and_close'=>0]); // Change mode here
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo '<pre>';
var_dump(session_id(), $_SESSION['test']);
Old behavior was around 15000 reqs/sec.
"read_and_close" improved it to about 20000 reqs/sec. i.e 33% faster.
"lazy_write" did not improve # of reqs, but per process httpd disk writes
was reduced from 100 MB/s to 5 MB/s. i.e. There were 12 httpd processes,
1200 MB/s writes was reduced to 60 MB/s writes.
I think this would be good enough benchmark for merging.
As you can see, lazy_write didn't improve files much. The reason is my
current Linux
kernel already does lazy_write for files aren't changed. I'm using Fedora
21 x86_64.
However, per process writes are reduced from 1200MB/s to 60MB/s writes.
60MB/s
writes includes writes to log. This means network traffic will be reduced.
It should
help many apps use memcached save handler.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hey:
Hi Xinchen,
Hi Rasmus,
On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.The diff is easy enough to grab:
git clone https://github.com/php-memcached-dev/php-memcached.git
cd php-memcached
git checkout php7
git diff master php7It looks like this:
It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.nice，thanks
btw did you bench your optimization on file handler against Wordpress?No I don't, but I have some numbers.
https://github.com/php/php-src/pull/1016
I've tried to get some benchmarks. It seems current system is too fast to
get obvious performance difference.Test command: ab -c 7 -n 500000 http://localhost:8888/session.php
Test script:<?php
ini_set('session.save_path', '/home/tmp');
ini_set('session.lazy_write', 1); // Change mode here
ini_set('session.use_strict_mode', 0);session_id('testid');
session_start(['read_and_close'=>0]); // Change mode here
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo '<pre>';
var_dump(session_id(), $_SESSION['test']);Old behavior was around 15000 reqs/sec.
"read_and_close" improved it to about 20000 reqs/sec. i.e 33% faster.
"lazy_write" did not improve # of reqs, but per process httpd disk writes
was reduced from 100 MB/s to 5 MB/s. i.e. There were 12 httpd processes,
1200 MB/s writes was reduced to 60 MB/s writes.I think this would be good enough benchmark for merging.
As you can see, lazy_write didn't improve files much. The reason is my
current Linux
kernel already does lazy_write for files aren't changed. I'm using Fedora 21
x86_64.However, per process writes are reduced from 1200MB/s to 60MB/s writes.
60MB/s
writes includes writes to log. This means network traffic will be reduced.
It should
help many apps use memcached save handler.
I've benched wordpress, didn't see any obviously speedup.
thanks
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi all,
It looks like this:
It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.
My environment is
[yohgaki@dev helm]$ rpm -q memcached
memcached-1.4.17-3.fc21.x86_64
I've just built it with current master/php7 branch and I got
Without Valgrind
FAILED TEST SUMMARY
Memcached::cas() with strange key
[ext/memcached/tests/experimental/cas_invalid_key.phpt]
Memcached::deleteByKey()
[ext/memcached/tests/experimental/delete_bykey.phpt]
Memcached::get() [ext/memcached/tests/experimental/get.phpt]
Memcached::getByKey() with CAS
[ext/memcached/tests/experimental/get_bykey_cas.phpt]
Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt]
=====================================================================
WARNED TEST SUMMARY
Memcached store, fetch & touch expired key
[ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes)
With Valgrind
FAILED TEST SUMMARY
Memcached::cas() with strange key
[ext/memcached/tests/experimental/cas_invalid_key.phpt]
Memcached::deleteByKey()
[ext/memcached/tests/experimental/delete_bykey.phpt]
Memcached::get() [ext/memcached/tests/experimental/get.phpt]
Memcached::getByKey() with CAS
[ext/memcached/tests/experimental/get_bykey_cas.phpt]
Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt]
=====================================================================
WARNED TEST SUMMARY
Memcached store, fetch & touch expired key
[ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes)
=====================================================================
LEAKED TEST SUMMARY
Memcached::set()/delete() UDP
[ext/memcached/tests/experimental/get_udp.phpt]
Memcached::setMultiByKey()
[ext/memcached/tests/experimental/setmulti_bykey.phpt]
Memcached::setMulti() [ext/memcached/tests/setmulti.phpt]
If this is normal, I'll ignore them all and start adopting new save handler
API.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hey:
Hi all,
It looks like this:
It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.My environment is
[yohgaki@dev helm]$ rpm -q memcached
memcached-1.4.17-3.fc21.x86_64I've just built it with current master/php7 branch and I got
Without Valgrind
FAILED TEST SUMMARY
Memcached::cas() with strange key
[ext/memcached/tests/experimental/cas_invalid_key.phpt]
Memcached::deleteByKey()
[ext/memcached/tests/experimental/delete_bykey.phpt]
Memcached::get() [ext/memcached/tests/experimental/get.phpt]
Memcached::getByKey() with CAS
[ext/memcached/tests/experimental/get_bykey_cas.phpt]
Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt]=====================================================================
WARNED TEST SUMMARYMemcached store, fetch & touch expired key
[ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes)With Valgrind
FAILED TEST SUMMARY
Memcached::cas() with strange key
[ext/memcached/tests/experimental/cas_invalid_key.phpt]
Memcached::deleteByKey()
[ext/memcached/tests/experimental/delete_bykey.phpt]
Memcached::get() [ext/memcached/tests/experimental/get.phpt]
Memcached::getByKey() with CAS
[ext/memcached/tests/experimental/get_bykey_cas.phpt]
Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt]=====================================================================
WARNED TEST SUMMARYMemcached store, fetch & touch expired key
[ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes)=====================================================================
LEAKED TEST SUMMARYMemcached::set()/delete() UDP
[ext/memcached/tests/experimental/get_udp.phpt]
Memcached::setMultiByKey()
[ext/memcached/tests/experimental/setmulti_bykey.phpt]
Memcached::setMulti() [ext/memcached/tests/setmulti.phpt]
The fails must be know... relates to key name checking
the leaks needs to be take care, I will look into it.
anyway, these should not affects your work,
thanks
If this is normal, I'll ignore them all and start adopting new save handler
API.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi Xinchen,
The fails must be know... relates to key name checking
the leaks needs to be take care, I will look into it.
anyway, these should not affects your work,
I think so. I'll start working :)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
The fails must be know... relates to key name checking
the leaks needs to be take care, I will look into it.
anyway, these should not affects your work,
I think so. I'll start working :)
Since my system isn't busy at all, there would be something wrong.
Memcached is vanilla package from Fedora 21 without any turning.
PHP/Apache are debug build.
Anyway, current figure is
lazy_write=On: Requests per second: 2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second: 24.58 [#/sec] (mean)
Session has rather large about 100KB data for benchmark purpose.
I'll test a little more and send PR later.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
The fails must be know... relates to key name checking
the leaks needs to be take care, I will look into it.
anyway, these should not affects your work,
I think so. I'll start working :)
Since my system isn't busy at all, there would be something wrong.
Memcached is vanilla package from Fedora 21 without any turning.
PHP/Apache are debug build.Anyway, current figure is
lazy_write=On: Requests per second: 2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second: 24.58 [#/sec] (mean)
I feel.......that might be something wrong :<
thanks
Session has rather large about 100KB data for benchmark purpose.
I'll test a little more and send PR later.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi Xinchen,
lazy_write=On: Requests per second: 2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second: 24.58 [#/sec] (mean)
I feel.......that might be something wrong :<
I do think so. It's Core i7 with 32GB memory and SSD. It did not use
much CPU and network bandwidth during benchmark. I'll wait your fix
(seems unrelated, though) and look into what's wrong. I cannot take
realistic benchmark because of this. I might try it on older machines :(
If you could take simple session benchmark, number of request / second,
it would be helpful for me to know my system's health.
session.php
<?php
//ini_set('session.save_path', '/home/tmp');
ini_set('session.save_path', 'PERSISTENT=1 127.0.0.1:11211');
ini_set('session.save_handler', 'memcached');
ini_set('session.lazy_write', 1);
ini_set('session.use_strict_mode', 0);
session_id('testid2');
session_start();
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo '<pre>';
var_dump(session_id(), ini_get('session.save_handler'), $_SESSION['test']);
?>
I get about 15K Reqs/sec for files handler with debug build.
Regards.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hey:
Hi Xinchen,
lazy_write=On: Requests per second: 2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second: 24.58 [#/sec] (mean)
I feel.......that might be something wrong :<I do think so. It's Core i7 with 32GB memory and SSD. It did not use
much CPU and network bandwidth during benchmark. I'll wait your fix
(seems unrelated, though) and look into what's wrong. I cannot take
Memcached::setMultiByKey()
[ext/memcached/tests/experimental/setmulti_bykey.phpt]
Memcached::setMulti() [ext/memcached/tests/setmulti.phpt]
are fixed. the other one seems in libmemcached side(get_udp.phpt)
realistic benchmark because of this. I might try it on older machines :(
If you could take simple session benchmark, number of request / second,
it would be helpful for me to know my system's health.
hmm, I will try later
thanks
session.php
<?php
//ini_set('session.save_path', '/home/tmp');
ini_set('session.save_path', 'PERSISTENT=1 127.0.0.1:11211');
ini_set('session.save_handler', 'memcached');
ini_set('session.lazy_write', 1);
ini_set('session.use_strict_mode', 0);session_id('testid2');
session_start();
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo '<pre>';
var_dump(session_id(), ini_get('session.save_handler'), $_SESSION['test']);
?>I get about 15K Reqs/sec for files handler with debug build.
Regards.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi Rasmus,
Rasmus Lerdorf rasmus@lerdorf.com writes:
It looks like this:
https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments. But is there
something more suited for this out there?
Maybe something like this would help? http://underscorejs.org/docs/underscore.html
-Rasmus
Cheers,
--
Florian Margaine
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments.
I think that's a good idea. It is very easy for people to ask
questions about any change that they don't understand on the exact
lines that are confusing them.
Also, I found it useful when converting Imagick to have a checklist of
everything that needed to be done, in a simple format, rather than the
full explanation of the changes at
https://wiki.php.net/phpng-upgrading. That allowed me to search for
the things that needed fixing.
You could then put links to the PR from checklist for an example of
the change in place.
cheers
Dan
An incomplete checklist for migrating an extension to PHP7
- Parse parameters changed from zval ** to just zval*
- zval **pzv;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "Z", &pzv) == FAILURE) {
- zval *zv;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", &zv) == FAILURE) {
- Geting value from a reference has changed:
- if (Z_ISREF_P(zv) && Z_TYPE_P(zv) == IS_ARRAY) {
- if (Z_ISREF_P(zv) && Z_TYPE_P(Z_REFVAL_P(zv)) == IS_ARRAY) {
- remove IS_BOOL, replace with IS_TRUE or IS_FALSE
- if ((Z_TYPE_PP(item) == IS_BOOL || Z_TYPE_PP(item) == IS_LONG) &&
Z_LVAL_PP(item)) {
- if (Z_TYPE_P(item) == IS_TRUE || (Z_TYPE_P(item) == IS_LONG &&
Z_LVAL_P(item))) {
- change Z_ADDREF_P
- Z_ADDREF_P(zv)
- if (Z_REFCOUNTED_P(zv)) {Z_ADDREF_P(zv);}
or equivalently
- Z_TRY_ADDREF_P(zv);
-
zval values should be copied using ZVAL_COPY_VALUE() macro
-
Nulling things
If you converted a zval* into a zval and previously usedNULLto
indicate an undefined value,
you can now use the IS_UNDEF type instead. It can be set using
ZVAL_UNDEF(&zv) and
checked using if (Z_ISUNDEF(zv)). -
Copying zvals to avoid modification not needed as much. You can get
the value directly.
- zval tmp;
- ZVAL_COPY_VALUE(&tmp, zv);
- zval_copy_ctor(&tmp);
- convert_to_string(&tmp);
- // ...
- zval_dtor(&tmp);
- zend_string *str = zval_get_string(zv);
- // ...
- STR_RELEASE(str);
- Change string access from Z_STRVAL_P for intern checking
- if (IS_INTERNED(Z_STRVAL_P(zv))) {
- if (IS_INTERNED(Z_STR_P(zv))) {
- Creation of zval_string, remove redundant param
- ZVAL_STRINGL(zv, str, len, 1);
- ZVAL_STRINGL(zv, str, len);
- ZVAL_STRING(zv, str, 0);
- ZVAL_STRING(zv, str);
- efree(str);
- Zend_hash_find has changed
- if (zend_hash_find(ht, Z_STRVAL_P(key), Z_STRLEN_P(key)+1,
(void**)&zv_ptr) == SUCCESS) {
- if ((zv = zend_hash_find(ht, Z_STR_P(key))) != NULL) {
- Change zend_string is used instead of char * and len for parameters
- char *str;
- int len;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &str,
&len) == FAILURE) {
- zend_string *str;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "S", &str) == FAILURE) {
- References access has changed.
- zval **ret;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "Z", &ret) == FAILURE) {
- zval *ret;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z/", &ret) == FAILURE) {
return;
}
- ZVAL_LONG(*ret, 0);
- ZVAL_LONG(ret, 0);
- Arrays are initialised with
- MAKE_STD_ZVAL(tmp);
- array_init(tmp);
- ZVAL_NEW_ARR(&tmp);
- array_init(&tmp);
- Iterating over a hash has a macro, and the key has been changd to zend_ulong
- ulong num_key;
- zend_ulong num_key;
- for (zend_hash_internal_pointer_reset(Z_ARRVAL_P(param_array));
- zend_hash_get_current_data(Z_ARRVAL_P(param_array), (void **)
&ppzval) == SUCCESS; - zend_hash_move_forward(Z_ARRVAL_P(param_array)), i++)
- {
-
ZEND_HASH_FOREACH_KEY_VAL(Z_ARRVAL_P(param_array), num_key, key, pzvalue) {
-
zval tmp_zval, *tmp_pzval;
-
long value = 0;
-
} ZEND_HASH_FOREACH_END();
-
Remove all MAKE_STD_ZVAL and turn those variables from "zval
*zv;" to "zval zv;" -
TSRM macros now do nothing. They can either be left in place or
removed if you do not need to support 5.x
Also, I found it useful when converting Imagick to have a checklist of
everything that needed to be done, in a simple format, rather than the
full explanation of the changes at
Is that in a publishable format Dan?
I'm looking to pull magickwand up as well but still a little lost on
what needs doing ...
Also I still have not fathomed out why I don't get a list of extensions
for imagick ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Dan,
Any suggestions for how to handle annotating it? We could turn it into
a fake PR and mark it up using github's PR comments.I think that's a good idea. It is very easy for people to ask
questions about any change that they don't understand on the exact lines
that are confusing them.Also, I found it useful when converting Imagick to have a checklist of
everything that needed to be done, in a simple format, rather than the full
explanation of the changes at https://wiki.php.net/phpng-upgrading. That
allowed me to search for the things that needed fixing.You could then put links to the PR from checklist for an example of
the change in place.
regarding your ext/imagick port, please check the make logs here
http://windows.php.net/downloads/pecl/snaps/imagick/3.2.0rc1/logs/ . How
it looks, you also might find this tool useful
https://github.com/johannes/clang-php-checker/ .
Thanks.
Anatol
Dan Ackroyd in php.internals (Fri, 6 Feb 2015 16:16:09 +0000):
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments.
(...)
An incomplete checklist for migrating an extension to PHP7
[snip]
Despite the extensive list of changes, imagick does not compile anymore
with the current PHP7 git head (Win32 VC11).
Jan
Despite the extensive list of changes, imagick does not compile anymore
with the current PHP7 git head (Win32 VC11).
OK another day wasted but I am getting the development platform stable.
http://lsces.org.uk/phpinfo.php is my production copy, but has a broken
imagick and an out of date smarty library.
http://php7.lsces.org.uk/phpinfo.php has everything it needs and is
currently only giving nginx errors in the log
http://php56.lsces.org.uk/phpinfo.php has the latest 5.6 from git but
mbstring will not compile
http://php6.lsces.org.uk/phpinfo.php is the distributed PHP5.6.5 dump
and everything seems to be working same as php7 build, except imagick
crashes phpinfo() as does the php56 build.
Just need to restore the production copy to fully functional before I
get back to debugging the new stuff.
( Have some facilities set up in Eclipse but would still appreciate some
input on that for compiling source rather than managing php projects )
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Despite the extensive list of changes, imagick does not compile anymore
with the current PHP7 git head (Win32 VC11).
Jan ... try the latest code from Dan ...
Just got both php7 and php5.6.5 running including a populated phpinfo on
each so I'm moving on ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine in php.internals (Mon, 09 Feb 2015 21:39:16 +0000):
Despite the extensive list of changes, imagick does not compile anymore
with the current PHP7 git head (Win32 VC11).Jan ... try the latest code from Dan ...
Just got both php7 and php5.6.5 running including a populated phpinfo on
each so I'm moving on ...
It was a VC11 specific error. I trimmed a lot of errors down to 1 pull
request:
https://github.com/mkoppanen/imagick/pull/74
Jan
Dan Ackroyd in php.internals (Fri, 6 Feb 2015 16:16:09 +0000):
An incomplete checklist for migrating an extension to PHP7
php_imagick (phpseven branch) once again does not compile, this time
because MAKE_STD_ZVAL has been removed and you added it in
imagickkernel_class.c with this commit:
https://github.com/mkoppanen/imagick/commit/a3cc177f8ed38937960e27765816e2f7a6de7391
The removal of MAKE_STD_ZVAL is documented in
https://wiki.php.net/phpng-upgrading
Jan
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.
UPGRADING.INTERNALS is far from complete. Take for instance the
substantial changes in zend_hash_index_find(_ptr). Look at
PHP_FUNCTION(dba_list) in dba.c. In PHP 5.6 that is
if (zend_hash_index_find(&EG(regular_list), i, (void **) &le)==FAILURE)
{
continue;
}
PHP7:
if ((le = zend_hash_index_find_ptr(&EG(regular_list), i)) == NULL) {
continue;
}
You'll have to use another macro, with a different number of arguments
and a different false test. There is nothing in UPGRADING.INTERNALS on
this. The info on this change can be found in the Wiki:
https://wiki.php.net/phpng-upgrading
But the wiki on its turn is not complete either. For instance it still
mentions
ZEND_FETCH_RESOURCE2(ib_link, ibase_db_link *, link_arg, link_id,
LE_LINK, le_link, le_plink);
Since the API cleanup interbase does not compile anymore. The reason is
that the API cleanup brought substantial changes in
ZEND_FETCH_RESOURCE2. I guess this command now must be something like
ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);
But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
#define GET_MOVIE_RESOURCE(ff_movie_ctx) {
zval **_tmp_zval;
if (zend_hash_find(Z_OBJPROP_P(getThis()), "ffmpeg_movie",
sizeof("ffmpeg_movie"), (void *)&_tmp_zval) == FAILURE) {
zend_error(E_WARNING, "Invalid ffmpeg_movie object");
RETURN_FALSE;
}
ZEND_FETCH_RESOURCE2(ff_movie_ctx, ff_movie_context, _tmp_zval, -1,
"ffmpeg_movie", le_ffmpeg_movie, le_ffmpeg_pmovie);
}\
I have tried a lot of things, but nothing works so far...
An annotated diff would be very welcome! But more or less complete
documentation as well.
Jan
Hello Jan,
An annotated diff would be very welcome! But more or less complete
documentation as well.Jan
What about placing such informations in the section of PHP manual like
http://php.net/manual/en/internals2.php (for ZE3, of course). I suspect
that writing regular text files in repo or updating page on the wiki is
faster, but, well, I also think that's what we have documentation for.
It would also allow us to remove some documentation files from php-src,
like:
- README.EXT_SKEL
- README.NEW_OUTPUT_API
- README.PARAMETERS_PARSING_API
- README.STREAMS
- README.TESTING
- README.TESTING2
- README.UNIX-BUILD-SYSTEM
- README.WIN32-BUILD-SYSTEM
- README.input_filter
- README.namespaces
or even guidelines for developers such as coding standards, release
process etc.
We have many informations, which can live in more suitable place, IMO.
I'm totally aware that those files are tend to be more up-to-date thanks
to placing them directly where core developers work. However, we have
wiki pages for internals stuff, so why not move it to the manual and
provide better "Zend Hacker's Guide"? There were some complaints about
its incompleteness and creation of Zend Engine 3 is a great opportunity
to fix it.
I know that you don't have much time - core development is much more
important and it's understandable, but please consider this proposal. I
can help with directly porting files mentioned above and changes for ZE3
from wiki and UPGRADING.INTERNALS if it will help somehow. If so, be
aware that I don't have skills to check its meritorical correctness, though.
Regards,
Maciej.
Hi Maciej,
I'm totally aware that those files are tend to be more up-to-date thanks
to placing them directly where core developers work. However, we have wiki
pages for internals stuff, so why not move it to the manual and provide
better "Zend Hacker's Guide"? There were some complaints about its
incompleteness and creation of Zend Engine 3 is a great opportunity to fix
it.
Manual build system is awesome, but writing manual is pain indeed
because it's sgml. For new release, updating the manual to current
state would be difficult. We have missing items even in text files in
source. I agree with you in general, but it's just not feasible it seems.
I also have number of doc bugs that are not fixed yet...
I had to spent few hours to know/get used to ZE3 API. However, thanks
to folks who ported most of modules, I didn't had much problem. ZE3
API is more developer friendly than ZE2 as well.
Basic stuff should be in source. IMO.
Perhaps, we should use only the Wiki for additional internal stuff from now
on.
Keeping in sync wiki and manual seems to hard, but nobody will prevent make
this effort if you would like to. ZE3 manual section is nice to have, but
it may
be better to use only wiki until we release PHP7.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo
OhgakiBasic stuff should be in source. IMO.
Perhaps, we should use only the Wiki for additional internal stuff from now
on.
+1. Documenting Zend API in docbook format is unrealistic. The whole ' PHP at the Core' chapter should go to the wiki and be replaced with a link.
Another reason is that the manual is supposed to be translated, but this part is not, and does not have to be.
Regards
François
Hey:
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.UPGRADING.INTERNALS is far from complete. Take for instance the
substantial changes in zend_hash_index_find(_ptr). Look at
PHP_FUNCTION(dba_list) in dba.c. In PHP 5.6 that isif (zend_hash_index_find(&EG(regular_list), i, (void **) &le)==FAILURE)
{
continue;
}PHP7:
if ((le = zend_hash_index_find_ptr(&EG(regular_list), i)) == NULL) {
continue;
}You'll have to use another macro, with a different number of arguments
and a different false test. There is nothing in UPGRADING.INTERNALS on
this. The info on this change can be found in the Wiki:
https://wiki.php.net/phpng-upgradingBut the wiki on its turn is not complete either. For instance it still
mentionsZEND_FETCH_RESOURCE2(ib_link, ibase_db_link *, link_arg, link_id,
LE_LINK, le_link, le_plink);Since the API cleanup interbase does not compile anymore. The reason is
that the API cleanup brought substantial changes in
ZEND_FETCH_RESOURCE2. I guess this command now must be something likeib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
these are changes are made recently, I've updated the relates section
in that wiki.
thanks
#define GET_MOVIE_RESOURCE(ff_movie_ctx) {
zval **_tmp_zval;
if (zend_hash_find(Z_OBJPROP_P(getThis()), "ffmpeg_movie",
sizeof("ffmpeg_movie"), (void *)&_tmp_zval) == FAILURE) {
zend_error(E_WARNING, "Invalid ffmpeg_movie object");
RETURN_FALSE;
}
ZEND_FETCH_RESOURCE2(ff_movie_ctx, ff_movie_context, _tmp_zval, -1,
"ffmpeg_movie", le_ffmpeg_movie, le_ffmpeg_pmovie);
}\I have tried a lot of things, but nothing works so far...
An annotated diff would be very welcome! But more or less complete
documentation as well.Jan
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Xinchen Hui in php.internals (Mon, 9 Feb 2015 14:49:43 +0800):
https://wiki.php.net/phpng-upgrading
[snip]
ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
these are changes are made recently, I've updated the relates section
in that wiki.
Thanks. The wiki now contains my educated guess with an alternative if
you know nothing about link_arg's type. Could you apply the PHP7 changes
to ext/interbase/interbase.c as well? The Wiki is inconsistent with the
actual PHP7 sources at the moment...
BTW, this seems to be a copy/paste error in the Wiki:
- if (zend_hash_find(EG(class_table), Z_STRVAL_P(key),
Z_STRLEN_P(key)+1, (void**)&ce_ptr) == SUCCESS) {
- if ((func = zend_hash_find_ptr(ht, Z_STR_P(key))) != NULL) {
Jan
Can we just use PHP7 instead of PHPNG in the wiki, that might be misleading.
Xinchen Hui in php.internals (Mon, 9 Feb 2015 14:49:43 +0800):
https://wiki.php.net/phpng-upgrading
[snip]
ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
these are changes are made recently, I've updated the relates section
in that wiki.Thanks. The wiki now contains my educated guess with an alternative if
you know nothing about link_arg's type. Could you apply the PHP7 changes
to ext/interbase/interbase.c as well? The Wiki is inconsistent with the
actual PHP7 sources at the moment...BTW, this seems to be a copy/paste error in the Wiki:
- if (zend_hash_find(EG(class_table), Z_STRVAL_P(key),
Z_STRLEN_P(key)+1, (void**)&ce_ptr) == SUCCESS) {
- if ((func = zend_hash_find_ptr(ht, Z_STR_P(key))) != NULL) {
Jan
--
--
Reeze Xia
http://reeze.cn