I don't see any active developers in over 5 months, looking at the CVS (link top of this page) for mmcache. Perhaps we can combine the mmcache and PHPA communities into a single project?
It would be a good thing if a coder from php-accelerator could join Turck, but I'm scared of the thought of merging the source codes.
Turck is quite complete in features, I think, and it's also efficient. What's needed is some stability and bug fixing.
TurckMMCache will die. Transformed into an other project.
A project will be published on sourceforge in some days (weeks?), based on turckmmcache. I can't say everything else because i'm nobody in this new project. Just be patient and enjoy :)
Could tell us if there is any further news on this new project?
No news from the 'new' dev team of the project for moment. I'm making a wiki to explain situation.
Hope this team has not abandon, cause no answer from the coordinator's project for now.
I would like to make a renumerated bugs list, sponsorized by AFUP (www.afup.org) , but we can only inject serious donation into a fondation or something like that, not just into a developper in a corner of the world.
Sorry for theses bad news, hope write better things next time...
shin seung woo
recently, I was working on mmcache code to work properly with php5 personally. and I found that 2.4.7's code is really close to it.
so, I'd like to join this project as a developer. How should I do?
"2.4.7's code is really close to it", i'm not agree with you, just make a unset() of a undefined variable in a function in a class, you will see a nice segfault. IPAtlas segfault too, to many segmentation fault. Encoded php files segfault more.
"I was working on mmcache code to work properly with php5", do you make some change since 2.4.7 ?
"so, I'd like to join this project as a developer. How should I do?", you must contact every developpers, perhaps except Dmitry, and ask to be a contributor.
You are welcome :)
>> "I was working on mmcache code to work properly with php5", do you make some change since 2.4.7 ?
yes, I was working from now on, and I think I soon got stable version, excepting encoder.
IMHO, 2.4.7 has relativly small bugs, but these bugs happens at every situtation. because php5 and php4 is not really different. they have same Z-value, same Hash API, same op codes.
diffrent part is only zend_class_entry. the only thing we need to do is reconstruct "struct zend_class_entry *" correctly.
>> "so, I'd like to join this project as a developer. How should I do?", you must contact every developpers, perhaps except Dmitry, and ask to be a contributor.
wow, It's really tough job, I think it will be a lot harder job than coding it self, especially with my poor english.
Hi! You are right, the bugs are really small ones. To fix a bug it is enough to modify the sources at one or two place. The code is nice and I really loved to work with it. No need to separate a branch. Please prepare MINIMISED test scripts to reproduce those unexpected behaviors, and I'll work on the code at holidays. 1 or 2 week sould be enough to cancel bugs. Kelvin helped a lot with his scripts earlier. If he or anyone else would be so kind to collect and verify a test script package, then I'll be on debugging.
> You are right, the bugs are really small ones.
I'm agree. Critical, but small fixes.
> The code is nice and I really loved to work with it.
It's definitly not the opinion of Rasmus :))) but it's not a problem for the end user.
>Please prepare MINIMISED test scripts to reproduce those unexpected behaviors,
Personaly, i can make some segfault scripts.
Give you some news later.
Good news for 'other' project based on turckmmcache :
> Hi Franck,
> we will release next week the first package. We was a little in trouble
> with a other project which we must finish in time.
> Am Dienstag, den 30.11.2004, 10:45 +0100 schrieb franck:
>>got news about your project ?
>>Hoesh & segv74 back on the forum of turckmmcache, preparing some hacks ...
Perhaps be just a little bit patient :)
I hope that this will not be a dead-end road again. I usually prefer real community projects, not one-company-driven ones.
Perhaps someone like hoesh (is Endre your firstname?) should ask Dmitry to give the project administration to him. So the project could continue and new members could be added etc.
If Dmitry will not, then let's fork the project (this is GNU GPL anyways) and work on without him. I don't think he has got any interrest left, not with his new employer.
I am willing to help with project coordination, creating docs, helping with a homepage etc. As for coding, I think there are some more talented people around. I think all that is needed is some coordination effort to bring together all of us interested in this project and start moving.
>I hope that this will not be a dead-end road again
>I usually prefer real community projects, not one-company-driven ones.
Don't forget Turckmmcache got his name cause of Turcksoftware company, previous job of Dmitry. Please take a look at the license of TurckMMCache : it's not clear, like manuel lemos said before.
>If Dmitry will not, then let's fork the project (this is GNU GPL anyways) and work on without him.
That's exactly what is appenning
>As for coding, I think there are some more talented people around
We need them :)
> and start moving
I think that's exactly what is appenning. If Hoesh and segv74 commit some changes on TurckMMCache source code, i will notice them to compare with the first commit of this anymous project (for moment), cause it's supposed to be based on TurckMMCache code philosophie.
Don't worry about all that, we must continu work around TurckMMCache since this anonymous project is not released. I suppose bugs corrected in turckMMCache will be things to verify in this new anonymous project.
> Don't forget Turckmmcache got his name cause of
> Turcksoftware company, previous job of Dmitry.
> Please take a look at the license of
> TurckMMCache : it's not clear, like manuel lemos
> said before.
Of course the forked projekt would need to find a new name. But for the license: as far as I see, the project is licensed under the GPL, which means that a fork could be done. At least the LICENSE file contains the GPL version 2.2. Am I wrong?
> If Hoesh and segv74 commit some changes on
> TurckMMCache source code
That is where I see the problem: segv74 can't commit any changes because he is no project member. And as far as I understand only a project administrator can add him... Dmitry.
Perhaps I am wrong here?
Again, I guess you will want to help in some areas, but you are not a project member and can't become one, except through Dimitry. It is therefore that I suggest that either one of the current project members will ask Dimitry to give them administrator status...
GPL: you're right.
Give administrator status: You're right too.
I write a mail to Dmitry now and give you feedback.
Sorry, before sending mail to Dmitry, just a question :
If i give temporaly to every body who wants a ssh CVS Access on one of my server, perhaps we can continu to work on source code without having a long discution about name now and no need to have an administrator level ? Got Horde WebCVS (nice) and ssh is secure, just give me feedback of that. Got an entire website dedicated to TurckMMCache but cause of this story of "anonymous project based en turckmmcache", i've just make a password protection to make google no index of this.
Ths website is a little wiki with file upload enabled.
Perhaps we can work on this and go back on sourceforge after decide of a new name and after see if the "anonymous project based on turckmmcache" is really good.
What do you think about that ?
Well, if dmitry is willing to cooperate, than it would be extra work to merge changes back. Otherwise it's a good idea perhaps. But that should be answered by those who would work on the code.
IMHO, I don't think it's good to give CVS commit privileges to more than 3 to 5 people. That could become quite a mess. Others should send patches. The committers should be chosen in discussion. And the commit messages should be sent to some mailling list so one can keep track.
Best Regards, Michael
Ok, I make a mail to Dmitry and prepare my server, I don't think it's the first time that Dmitry has been sollicited to give admin access and if i didn't give it, i suppose he will not give it today.
Give you feedback of the mail.
Thanks for your work.
Hoesh, do you think it's possible to have a tar.gz of /cvsroot/turck-mmcache ? . My WebCVS is ready but a simple checkout make me loose all of the history of TurckMMCache code ..
Going out of the screen.. let's get back to the top level of this discussion!
>Going out of the screen.. let's get back to the
>top level of this discussion!
So no need to branch code source for PHP5 stuff.
Let's start a new thread.
Mail to Dmitry has been send, I purpose Hoesh as and admin (just suggestion) and me (but i'm not really the good one i think) and I purpose that he make a choice :
- give an admin access (person he will choose)
- stay TurckMMCache as is, fork will be the rule.
Preparing my server while waiting for Dmitry answer.
on a few days of my working, I found that where is problem of current bug and how to solve. my version of mmcache is quite works well in my PC now. I will post what I found and my quick-ugly patch soon.
Last night I found that bug 1072815 has a little problem.
mmcache makes function / class name to lowercase. but, it makes every strings same as class/function name to lowercase.
With this feature, class Test in bug 1072815 is stored as lowercase 'test'. but, private $Test member variable is converted to lowercase too!
further more, in php5, people uses __autoload() without knowing that class/function name is case-insensitive.
I saw a lot of code such as $class_name == 'MyClass' / __CLASS__ == 'MyClass' / get_class($obj) == 'MyClass'.
so, I think that it would better revert this feature back.
@sorry for my poor english.
it takes me much more time than coding itself. :-(
i have noticed two bugs that cause a segfault. both it appears with php5 + mmcache.
one is with objects. it seems to cache the object after the first load and not execute it again (until the file is changed and forced to be recached) - even unset($object) wouldn't work (even though object persistence shouldn't be an issue since the object is killed after every request)
the other is using arrays in list() -
list($foo,$bar,$array['item']) = $something;
that $array['item'] causes a segfault. you can't put arrays in a list() anymore with php5+mmcache.
it could be a good thing or bad; but either way it's different behavior from php4. i had to change a bunch of code when i upgraded to php5 so it would stop segfaulting.