Hello, George Schlossnagle wrote: > > > - Add an API function that can compile arbitrary PHP scripts. > > How do you want to handle includes or evals in the code to be compiled? > This is a majopr problem I see with a naive standalone compiler.
I am not aware. What exactly is the problem? When I say compiler I mean PHP source to Zend bytecodes. The way I see it compiled included files should be loaded on demand with a function for instance named include_apc() that would simply load the code and run it. eval would be handled normally with Zend engine like any other PHP source code extract. > > - Add an API function for loading arbitrary compiled code. > > somewhat trickier. Why? > > - If possible these should take source input and generating compiled > > output to string so we can handle input and output data from other > > sources besides files. > > wouldn't be too hard, modulo the above. Great. > > These would be the basic this that would be necessary. > > > > Around this we could build other tools like GUI interfaces from > > compiling sources in batches, building distribution archives, self > > extracting and installable PHP applications, etc... > > > > > > Now, for something probably more challenging: could the compiled output > > be fed to Zend Optimizer somehow and get an optimized compiled output > > that could be saved, loaded and executed the same way as the > > non-optimized compiled output? > > No idea. closed source product. :) Oh, I see, undocumented API, right? Never mind, most people can live without it. It took me a while to realize that PHP pages can be served much faster efficiently just by using a cache extension like APC than just with Zend Optimizer. Actually, with all optimizations on, it seems that my site was running slower and consuming more CPU cycles when I just used Zend Optimizer. Ideally an optimizer could run before storing the compiled output to the cache or disk. We can live without Zend Optimizer. BTW, I talked with BWare people and they say they have good ideas for optimizing the compiled code. Even if that is not as good as the Zend Optimizer, it is better than raw compiled code. It seems that PHPA also does some optimization but since it is closed source and the author seems to be stalling to not share his code or ideas, we'd better not count on him unless he changes his posture. I don't have a problem with the fact that he closes the source (it is his sole right), but for this free PHP compiler project we can't rely on closed source projects. > >>> How Open Source is APC? Do you take volunteers help (patches, hackers > >>> with CVS accounts, bug reports, etc..)? > >> > >> APC is completely open-source (release under QPL). Patches are > >> awesome. CVS write-access is only for maintainers at the moment (and > >> anon cvs to the world). There's noo hard-and-fast rule, but the base > >> guideline for maintainer status is contribution fixes/patches of > >> consistent merit and of more than 10% of the code base. > > > > Great. And if PHP developers agree, would you be interested in > > integrating APC extension in PHP, with PHP license of course? > > I have no problems with relicensing APC, and I've offered before to > contribute it to the php group, and it was turned down. I can give > further details off-list, if you are interested. Sure I and a lot of people here would like to know why it was turned down. If you feel you can only tell me privately, please do so, but I think PHP is an Open Source project and therefore everybody envolved should be coherent and not hide the reasons why a contribution is accepted or rejected. Open Source is not consistent with secret decisions. So please, I am encouraging you to speak openly and let everybody know what was the reasoning for being excluded. > >>> I looked at all free cache engines (PHPA, APC, Bware). PHPA seems to > >>> be > >>> going to non-Open Source route (no code available for everybody). > >>> Bware > >>> people are nice and are willing to cooperate even if they don't have > >>> much time. APC, I could not realize how alive the the project is. Do > >>> you > >>> actively work on it or are you too busy? > >> > >> I haven't been very active since October (wish I could say it was a > >> vacation, but alas, it was just work). In about 3 weeks, I should have > >> much much more free time and hopefully be able to get back to being > >> very > >> active in apc. > > > > Ok, that's normal with everybody these days. Anyway, as I said I have > > been getting a lot of support to provide a free PHP > > compiler/optimizer/cache/encoder. So, this will not go forward for the > > lack of will and contributed work. > > That's great news. Yes, oh BTW, I would like to apologise to the numerous people that contacted me privately because I still did not have time to reply to them personally. I will do so ASAP. Regards, Manuel Lemos -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
