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 >> >> >> >
