Re: [PECL-DEV] Introduction: Szabi, extension: memcache
Or this one Szabolcs Balogh in php.pecl.dev (Thu, 18 Feb 2016 13:28:51 +0100): >Hi, > >I'm getting questions about merging this patch into php.net version, so i >would ask, that what are the requirements, what is the process for getting >this port to be merged? > >thanks for answer >szabi > >On Wed, Dec 2, 2015 at 2:15 PM, Szabolcs Balogh wrote: > >> Hi, >> >> i ported v 3.0.9-dev from branch NON_BLOCKING_IO to NON_BLOCKING_IO_php7, >> the original php5 version is buggy, mainly udp protocol doesn't work for >> me, as it is expected. >> after porting on php7 there is less failing tests, but udp is wrong there >> too, and test tests/039.phpt end's up in a loop for a long time. >> >> Windows not tested, i tried it, but tests are failing for php5 version as >> on php7 too. For ex. there are no checks for windows, so it's checking unix >> socket, ... >> >> digitalkaoz also tried it: >> https://github.com/websupport-sk/pecl-memcache/issues/2 >> >> On Sun, Nov 15, 2015 at 1:32 PM, Anatol Belski >> wrote: >> >>> Hi Szabolcs, >>> >>> > -Original Message- >>> > From: Szabolcs Balogh [mailto:balog...@szabi.org] >>> > Sent: Saturday, November 14, 2015 4:52 PM >>> > To: Anatol Belski >>> > Cc: Anthony Dovgal ; Pierre Joye >>> > ; pecl-dev@lists.php.net >>> > Subject: Re: [PECL-DEV] Introduction: Szabi, extension: memcache >>> > >>> > Hi Anatol >>> > >>> > i found one "little" problem >>> > >>> > i used memcache from >>> > https://git.php.net/repository/pecl/caching/memcache.git, master >>> branch, but >>> > it seems to be an after-2.2.7 branch, and the development, and new >>> releases are >>> > in NON_BLOCKING_IO branch till 3.0.6. >>> > And last release 3.0.8 is a tag with something like initial commit (all >>> code in >>> > without link to prev. commit, so not in tree). >>> > >>> > I think I need to a part of work again, get the 3.0.8 code and somehow >>> connect >>> > it to NON_BLOCKING_IO branch, and continue from this point, my only >>> question >>> > is, that can you look at this git tree, and confirm, that i am right >>> with this >>> > process. >>> > >>> Yeah, NON_BLOCKING_IO holds the current development. My bad as well not >>> catching it :( . But please note also that PHP5 compatible code should be >>> kept - so either a new branch or another way (like integrating 7 >>> compatibility with conditionals or picking different sources in >>> config.(m4|w32) depending on the version). >>> >>> Thanks >>> >>> Anatol >>> >>> >> -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Introduction: Szabi, extension: memcache
Hi, i ported v 3.0.9-dev from branch NON_BLOCKING_IO to NON_BLOCKING_IO_php7, the original php5 version is buggy, mainly udp protocol doesn't work for me, as it is expected. after porting on php7 there is less failing tests, but udp is wrong there too, and test tests/039.phpt end's up in a loop for a long time. Windows not tested, i tried it, but tests are failing for php5 version as on php7 too. For ex. there are no checks for windows, so it's checking unix socket, ... digitalkaoz also tried it: https://github.com/websupport-sk/pecl-memcache/issues/2 On Sun, Nov 15, 2015 at 1:32 PM, Anatol Belski <anatol@belski.net> wrote: > Hi Szabolcs, > > > -Original Message- > > From: Szabolcs Balogh [mailto:balog...@szabi.org] > > Sent: Saturday, November 14, 2015 4:52 PM > > To: Anatol Belski <anatol@belski.net> > > Cc: Anthony Dovgal <tony2...@php.net>; Pierre Joye > > <pierre....@gmail.com>; pecl-dev@lists.php.net > > Subject: Re: [PECL-DEV] Introduction: Szabi, extension: memcache > > > > Hi Anatol > > > > i found one "little" problem > > > > i used memcache from > > https://git.php.net/repository/pecl/caching/memcache.git, master > branch, but > > it seems to be an after-2.2.7 branch, and the development, and new > releases are > > in NON_BLOCKING_IO branch till 3.0.6. > > And last release 3.0.8 is a tag with something like initial commit (all > code in > > without link to prev. commit, so not in tree). > > > > I think I need to a part of work again, get the 3.0.8 code and somehow > connect > > it to NON_BLOCKING_IO branch, and continue from this point, my only > question > > is, that can you look at this git tree, and confirm, that i am right > with this > > process. > > > Yeah, NON_BLOCKING_IO holds the current development. My bad as well not > catching it :( . But please note also that PHP5 compatible code should be > kept - so either a new branch or another way (like integrating 7 > compatibility with conditionals or picking different sources in > config.(m4|w32) depending on the version). > > Thanks > > Anatol > >
RE: [PECL-DEV] Introduction: Szabi, extension: memcache
Hi Szabolcs, > -Original Message- > From: Szabolcs Balogh [mailto:balog...@szabi.org] > Sent: Saturday, November 14, 2015 4:52 PM > To: Anatol Belski <anatol@belski.net> > Cc: Anthony Dovgal <tony2...@php.net>; Pierre Joye > <pierre@gmail.com>; pecl-dev@lists.php.net > Subject: Re: [PECL-DEV] Introduction: Szabi, extension: memcache > > Hi Anatol > > i found one "little" problem > > i used memcache from > https://git.php.net/repository/pecl/caching/memcache.git, master branch, but > it seems to be an after-2.2.7 branch, and the development, and new releases > are > in NON_BLOCKING_IO branch till 3.0.6. > And last release 3.0.8 is a tag with something like initial commit (all code > in > without link to prev. commit, so not in tree). > > I think I need to a part of work again, get the 3.0.8 code and somehow connect > it to NON_BLOCKING_IO branch, and continue from this point, my only question > is, that can you look at this git tree, and confirm, that i am right with this > process. > Yeah, NON_BLOCKING_IO holds the current development. My bad as well not catching it :( . But please note also that PHP5 compatible code should be kept - so either a new branch or another way (like integrating 7 compatibility with conditionals or picking different sources in config.(m4|w32) depending on the version). Thanks Anatol -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Introduction: Szabi, extension: memcache
Hi Anatol
i found one "little" problem
i used memcache from
https://git.php.net/repository/pecl/caching/memcache.git, master branch,
but it seems to be an after-2.2.7 branch, and the development, and new
releases are in NON_BLOCKING_IO branch till 3.0.6.
And last release 3.0.8 is a tag with something like initial commit (all
code in without link to prev. commit, so not in tree).
I think I need to a part of work again, get the 3.0.8 code and somehow
connect it to NON_BLOCKING_IO branch, and continue from this point, my only
question is, that can you look at this git tree, and confirm, that i am
right with this process.
Thanks
On Thu, Nov 12, 2015 at 4:39 PM, Szabolcs Balogh <balog...@szabi.org> wrote:
> i found in the lastest tarball(3.0.8) of memcache module this test, which
> is ok:
>
> http://git.php.net/?p=pecl/caching/memcache.git;a=blob;f=tests/030.phpt;h=b1a109bd71434e2a932b9548662e916e29ba72fe;hb=85a86d8d0ce7c333a88bc378d5aca91dd5f910ff
>
> so i updated the test to this
>
> macros and the other test was fixed.
>
> On Wed, Nov 11, 2015 at 6:02 PM, Anatol Belski <anatol@belski.net>
> wrote:
>
>> Hi,
>>
>> > -Original Message-
>> > From: Szabolcs Balogh [mailto:balog...@szabi.org]
>> > Sent: Wednesday, November 11, 2015 2:49 PM
>> > To: Anatol Belski <anatol@belski.net>; pecl-dev@lists.php.net
>> > Cc: Anthony Dovgal <tony2...@php.net>; Pierre Joye <
>> pierre@gmail.com>
>> > Subject: Re: [PECL-DEV] Introduction: Szabi, extension: memcache
>> >
>> > Thanks for your advise.
>> >
>> > I was in wrong branch (7.0 instead of 7.0.0) so i found the right
>> > UPGRADING.INTERNALS now.
>> > I made some transforms to use zend_string instead of char*/int, and
>> fixed issues
>> > you mentioned, and some others I found in upgrading internals.
>> > Source is in master branch now on
>> > https://github.com/websupport-sk/pecl-memcache.
>> >
>> > Questions to UPRADING.INTERNALS:
>> >
>> > In memcache there is some sprintf, which doesn't support zend_long, and
>> in
>> > upgdate.internals is mentioned a macro ZEND_INT_FMT, but i didn't find
>> it in the
>> > source. I'm searching in wrong place, or how should be zend_long used in
>> > sprintf?
>> My bad, it's ZEND_LONG_FMT, the doc fixed. Declared in Zend/zend_long.h,
>> it should be used instead of %ld where suitable.
>>
>> >
>> > Which is preferred more on zend_strings, str->val access, or usage of
>> > ZSTR_VAL(str) macros? I found examples for both in php-src/ext/.
>> >
>> ZSTR_* macros are the preferred way.
>>
>> > Tests:
>> >
>> > I use 64bit ubuntu, and I have 2 failing tests:
>> > TEST: ini_set("memcache.chunk_size") [tests/030.phpt] tests setting
>> chunk_size
>> > to 0, and -1, which is not alloved ini_set by documentation should
>> return false
>> > on failed set, but the test expects string(5) "32768", which is the
>> last value.
>> > I dont want to change the test, because i'm not sure in this yet.
>> >
>> Not sure, but 32768 seems to be the default value. Or, as you say, it
>> could be the last successfully set value (but I doubt that). Should be
>> checked. The return value of ini_set depends on how it's implemented in the
>> concrete case (how it can be read from the test, memcache will just set a
>> default value in case of invalid input and report success).
>>
>> > TEST:memcache->getStats() with arguments [tests/034.phpt] Is failing
>> because
>> > of
>> > https://code.google.com/p/memcached/issues/detail?id=66 , "stat
>> malloc" was
>> > removed from memcache 1.4.
>> >
>> Ok, so I'd suggest the actual memcached instance version to be checked at
>> runtime. Then you skip this test for memcached >= 1.4 (and/or handle an
>> appropriate way internally). But this is not a php7 port issue, most likely
>> same thing in the php5 version (so the fix, if any, should be backported
>> there).
>>
>> > The rest of tests are passing, (and the tests had the same result when
>> i published
>> > this code.) I'm preparing to test this on windows 10 too, but it will
>> take some
>> > time for me.
>> >
>> I can do some testing on Windows this or next WE, please ping when you
>> think it should be done.
>>
>> Regards
>>
>> Anatol
>>
>>
>>
>
RE: [PECL-DEV] Introduction: Szabi, extension: memcache
Hi,
> -Original Message-
> From: Szabolcs Balogh [mailto:balog...@szabi.org]
> Sent: Wednesday, November 11, 2015 2:49 PM
> To: Anatol Belski <anatol@belski.net>; pecl-dev@lists.php.net
> Cc: Anthony Dovgal <tony2...@php.net>; Pierre Joye <pierre....@gmail.com>
> Subject: Re: [PECL-DEV] Introduction: Szabi, extension: memcache
>
> Thanks for your advise.
>
> I was in wrong branch (7.0 instead of 7.0.0) so i found the right
> UPGRADING.INTERNALS now.
> I made some transforms to use zend_string instead of char*/int, and fixed
> issues
> you mentioned, and some others I found in upgrading internals.
> Source is in master branch now on
> https://github.com/websupport-sk/pecl-memcache.
>
> Questions to UPRADING.INTERNALS:
>
> In memcache there is some sprintf, which doesn't support zend_long, and in
> upgdate.internals is mentioned a macro ZEND_INT_FMT, but i didn't find it in
> the
> source. I'm searching in wrong place, or how should be zend_long used in
> sprintf?
My bad, it's ZEND_LONG_FMT, the doc fixed. Declared in Zend/zend_long.h, it
should be used instead of %ld where suitable.
>
> Which is preferred more on zend_strings, str->val access, or usage of
> ZSTR_VAL(str) macros? I found examples for both in php-src/ext/.
>
ZSTR_* macros are the preferred way.
> Tests:
>
> I use 64bit ubuntu, and I have 2 failing tests:
> TEST: ini_set("memcache.chunk_size") [tests/030.phpt] tests setting chunk_size
> to 0, and -1, which is not alloved ini_set by documentation should return
> false
> on failed set, but the test expects string(5) "32768", which is the last
> value.
> I dont want to change the test, because i'm not sure in this yet.
>
Not sure, but 32768 seems to be the default value. Or, as you say, it could be
the last successfully set value (but I doubt that). Should be checked. The
return value of ini_set depends on how it's implemented in the concrete case
(how it can be read from the test, memcache will just set a default value in
case of invalid input and report success).
> TEST:memcache->getStats() with arguments [tests/034.phpt] Is failing because
> of
> https://code.google.com/p/memcached/issues/detail?id=66 , "stat malloc" was
> removed from memcache 1.4.
>
Ok, so I'd suggest the actual memcached instance version to be checked at
runtime. Then you skip this test for memcached >= 1.4 (and/or handle an
appropriate way internally). But this is not a php7 port issue, most likely
same thing in the php5 version (so the fix, if any, should be backported
there).
> The rest of tests are passing, (and the tests had the same result when i
> published
> this code.) I'm preparing to test this on windows 10 too, but it will take
> some
> time for me.
>
I can do some testing on Windows this or next WE, please ping when you think it
should be done.
Regards
Anatol
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Introduction: Szabi, extension: memcache
Thanks for your advise.
I was in wrong branch (7.0 instead of 7.0.0) so i found the right
UPGRADING.INTERNALS now.
I made some transforms to use zend_string instead of char*/int, and fixed
issues you mentioned, and some others I found in upgrading internals.
Source is in master branch now on
https://github.com/websupport-sk/pecl-memcache.
Questions to UPRADING.INTERNALS:
In memcache there is some sprintf, which doesn't support zend_long, and in
upgdate.internals is mentioned a macro ZEND_INT_FMT, but i didn't find it
in the source. I'm searching in wrong place, or how should be zend_long
used in sprintf?
Which is preferred more on zend_strings, str->val access, or usage of
ZSTR_VAL(str) macros? I found examples for both in php-src/ext/.
Tests:
I use 64bit ubuntu, and I have 2 failing tests:
TEST: ini_set("memcache.chunk_size") [tests/030.phpt]
tests setting chunk_size to 0, and -1, which is not alloved
ini_set by documentation should return false on failed set, but the test
expects string(5) "32768", which is the last value.
I dont want to change the test, because i'm not sure in this yet.
TEST:memcache->getStats() with arguments [tests/034.phpt]
Is failing because of
https://code.google.com/p/memcached/issues/detail?id=66 ,
"stat malloc" was removed from memcache 1.4.
The rest of tests are passing, (and the tests had the same result when i
published this code.)
I'm preparing to test this on windows 10 too, but it will take some time
for me.
On Tue, Nov 10, 2015 at 1:45 PM, Anatol Belski
wrote:
> Hi Szabolcs,
>
> > -Original Message-
> > From: Szabolcs Balogh [mailto:balog...@szabi.org]
> > Sent: Tuesday, November 10, 2015 1:04 PM
> > To: pecl-dev@lists.php.net
> > Subject: [PECL-DEV] Introduction: Szabi, extension: memcache
> >
> > Hi
> >
> > I'm writing there because of https://pecl.php.net/account-request.php.
> >
> > My name is Szabolcs Balogh(Szabi), working in a webhosting company, and
> > coding.
> >
> > I ported memcache extension to php7 in last weeks, code at:
> > https://github.com/websupport-sk/pecl-
> > memcache/commit/005a35cde8439a053632047eb28e59fcc8cb7ea2
> > bug-report at:
> > https://bugs.php.net/bug.php?id=70751
> >
> > So i want to help with this extension.
> >
> Great start!
>
> Just quick issue summary in your patch, UPGRADING INTERNALS contains the
> most information as well as the PHPNG wiki
>
> - ZPP 'l' format requires zend_long
> - ZPP 's' format requires size_t
> - ZEND_STRTOL is required (together with zend_long) instead of strtol
> (particularly for INI)
> - TSRM_* macros can be removed, and please specifically see the TSRM
> section in UPGRADING.INTERNALS
>
> You probably can spot some issues with 64-bit Linux/Windows builds.
>
> Thanks
>
> Anatol
>
>
