Re: [PHP-DEV] git anyone?
On Dec 1, 2010, at 5:16 PM, Johannes Schlüter wrote: On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote: On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. An evaluation requires a clear set of goals first. Like: Why change? What is broken? What can be improved? What are existing requirements? Once that is done one can start evaluating specific tools. Instead of doing this, how about concentrate in actual work for the next release? And IMO, there's nothing broken that needs fixing or changing to some DVCS since SVN works just fine.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+1 for PHP 7.0. :)
Stuff like this accumulating in trunk kinda makes it more and more
something else than minor release..
--Jani
27.11.2010 19:40, Johannes Schlüter kirjoitti:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to prevent conflicts, I therefore propose the
following RFC incl. patch to allow writing
class Foo {
public bar() {
echo Hello World;
}
}
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Who says it has to be 5.4? People seem to be a bit fixated on the version there. Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. ---Jani On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote: On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner m...@php.net wrote: On 11/23/2010 02:30 AM, Felipe Pena wrote: 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. The reality is that trunk is not going to be 5.4; it cannot be in its current state. The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing. The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This is an unreliable, laborious, crappy method for creating stable branches, and managing the repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and re-integrating is also a pretty crappy solution. So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work. Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now. We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories to more easily pull those changes into the appropriate branches. - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Is it just unusually cold weather for this time of year or did the hell just freeze over? :-o Couldn't agree more on both points and I had the same thoughts about getting stuck with 5.x releases forever. And not getting any release out soon from trunk if this thread drags on too long. Maybe even skip 6 like Andi proposed and declare that from now even major versions are never released. Only prime numbers count. 7 is a prime number and it's the lucky one too. ;) --Jani p.s. Somehow this reminds me of one particular discussion in around 2001 about the versioning scheme.. :D 25.11.2010 23:56, Zeev Suraski wrote: I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. 2. Maybe it's time to break the notion that a major number change means major breakage. Sometimes (like in Google Chrome), a major version can bring nothing but a few new features and significantly improve performance, without any additional pain. Not saying we should go to the extreme of releasing a major version every other week, but once a year or once every 18 months is a very reasonable frequency. Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). My 2c. Zeev -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010 7:55 PM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP Internals Subject: RE: [PHP-DEV] Re: Hold off 5.4 On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: This is no different in the Java world, C++ as it matured or some other technologies. Java is currently at 1.6. (and 6 in Marketing) :-) C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting for C++0x, whatever the actual name will be. No good examples ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Restructuring NEWS?
On Nov 19, 2010, at 11:38 AM, Johannes Schlüter wrote: On Fri, 2010-11-19 at 10:30 +0100, Johannes Schlüter wrote: And get rid of those ancient Changelog* files as well. :) I proposed this in the past. See http://www.mail-archive.com/internals@lists.php.net/msg46669.html If nobody creates a process for updating these files I will drop the ChangeLog* files before packaging 5.3.4RC2 in two weeks. The current state is useless. Do it also in trunk.. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Nov 18, 2010, at 12:12 PM, Johannes Schlüter wrote: Yes. We have to get rid of them! I was +1 for the old PHP 6 as that breaks so much stuff that it is nowhere a drop in replacement. And as such I'm happy to drop it in any release breaking lots of applications. I'm not happy about dropping it in a version which is a drop-in replacement in most cases. (count the BC breaks in trunk right now ..) UPGRADING file is quite long. And dropping register_globals, safe_mode, etc. quite likely breaks something? :) One way might be dropping the old mysql extension. Then everybody has to learn something else and while learning about that /might/ be reached with further education. Very good idea, move ext/mysql to PECL today? I think most applications (Wordpress, etc.) nowadays don't rely on magic_quotes_* or have done the usual magic to disable it anyway. So IMO, remove them in trunk and release it as something else than 5.4. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes in trunk
On Nov 18, 2010, at 12:41 PM, Patrick ALLAERT wrote: Disabling it by default is the first mandatory step, [done] in PHP 5.3, magic_quotes_gpc has been turned off by default at the same time as providing a -development and -production version of the php.ini file. AFAICT magic_quotes_gpc is still On in PHP_5_3 and trunk if you don't use any php.ini: $ php -n --ri core | grep magic magic_quotes_gpc = On = On magic_quotes_runtime = Off = Off magic_quotes_sybase = Off = Off Or what did you mean? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Restructuring NEWS?
19.11.2010 0:39, Johannes Schlüter kirjoitti: Hi, after the 5.3.3 release I was approached with the request to restructure the NEWS file -- for instance by grouping entries by extension -- so users can identify whether there are bug fixes relevant for them etc. Something that I did in trunk NEWS perhaps? I'd like a better formatted NEWS though. And get rid of those ancient Changelog* files as well. :) Ideas / examples of better format accepted, I can always implement it if time permits. It would also help if we can forget that 80 chars per line limit as well. It's 2k already and people do have bigger terminals nowadays. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] multiple sapi (multiple bug reports)
13.11.2010 23:24, Matti Bickel kirjoitti: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/13/2010 08:50 PM, Stanley Sufficool wrote: 2010/11/13 Jérôme Loyetjer...@loyet.net: Le 12 novembre 2010 23:57, Jani Taskinenjani.taski...@iki.fi a écrit : I updated the patch: http://pecl.php.net/~jani/patches/multi-sapi.patch Now it will fail if no sapi/binary is selected. And make install will now also install them all. :) it seems to work well. I think Gentoo already has a multiple SAPI build in their PHP patch set. We did, but dropped it for 5.3; I'll happily include any working patch. Above patch does work. And it's also committed to trunk now. PHP 5.3 propably will not get this, RM should decide. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] multiple sapi (multiple bug reports)
I updated the patch: http://pecl.php.net/~jani/patches/multi-sapi.patch Now it will fail if no sapi/binary is selected. And make install will now also install them all. :) The question remains: into what branches can I commit it? Some might think it's not a bug fix.. ;) --Jani 12.11.2010 10:23, Jérôme Loyet kirjoitti: 2010/11/12 Jani Taskinenjani.taski...@iki.fi: And here's the patch: http://pecl.php.net/~jani/patches/multi-sapi.patch Note: It's not quite finished, the 'make install' might not work.. ;) After a very quick try, there is a missing case: if not SAPI and no binaries have been selected, we should trigger an error message. The configture is terminating normaly et make does nothing (normal). ++ Jerome --Jani 12.11.2010 2:40, Jani Taskinen kirjoitti: I'm working on an improvement on how all binaries are build thus enabling building all such in one go if one wants to. I already added a check for multiple sapi _modules_ being build, it will error out. Stay tuned, I'll post the patch once I've tested it a bit. --Jani 12.11.2010 0:03, Jérôme Loyet kirjoitti: 2010/11/11 Jani Taskinenjani.taski...@iki.fi: 11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti: Hi Jérôme 2010/11/11 Jérôme Loyetjer...@loyet.net: If this is a normal behaviour, we should add an error at configure telling that only one SAPI is supported at once. It not, we should correct it. Did I miss something ? On Windows we have no problems in compiling multiple SAPI's using one ./configure, so I believe it is indeed a bug on the Unix build system causing this, so yeah I suppose it should be fixed. Sascha explained this briefly here: http://www.mail-archive.com/php-...@lists.php.net/msg00413.html I understand it's hard to compile mutiple SAPI (dependancies, linkage, ...). In this case, this should be clear at configure and an error message should be shown. It's not reasonable not to be able to compile CGI and apache2 sapi without any informations (like http://bugs.php.net/53271). I've made a quick patch (http://pastebin.com/jUGMtSjv) which: - move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses a config9.m4 file is to be called at configure as the last SAPI. - remove the No SAPI selected check in sapi/cgi/config.m4. To me it's not its job. It has to be done by configure. To me, the cgi sapi must be like any of the others - change the cgi sapi to be disable by default. cgi sapi will be like any other sapi (except cli), disable by default. Basically, PHP is a programming scripting language. The CLI has to be enable by default and other sapi have to be enabled by the user. - add a No SAPI selected check in configure.in, after esyscmd(./build/config-stubs sapi) (after all sapi config*.m4 files have been executed). Use CLI as default SAPI if it's not been disabled. If all SAPI and CLI have been disabled, issue the error message. - A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been called only once (all SAPI (except CLI) calls this macro). At second call, an error message telling that only one SAPI can be compiled is shown. I don't have a huge php core background but it seems (for me at least) the right way for users. hope it helps. Something called ZTS also comes to my mind.. It's not the first time ZTS comes in the discution about multiple SAPI. I've made some tests and looked into the code of the build chain, but I can't see how it's related. Maybe someone can enlight me ? thx ++ jerome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] multiple sapi (multiple bug reports)
11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti: Hi Jérôme 2010/11/11 Jérôme Loyetjer...@loyet.net: If this is a normal behaviour, we should add an error at configure telling that only one SAPI is supported at once. It not, we should correct it. Did I miss something ? On Windows we have no problems in compiling multiple SAPI's using one ./configure, so I believe it is indeed a bug on the Unix build system causing this, so yeah I suppose it should be fixed. Sascha explained this briefly here: http://www.mail-archive.com/php-...@lists.php.net/msg00413.html Something called ZTS also comes to my mind.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] multiple sapi (multiple bug reports)
I'm working on an improvement on how all binaries are build thus enabling building all such in one go if one wants to. I already added a check for multiple sapi _modules_ being build, it will error out. Stay tuned, I'll post the patch once I've tested it a bit. --Jani 12.11.2010 0:03, Jérôme Loyet kirjoitti: 2010/11/11 Jani Taskinenjani.taski...@iki.fi: 11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti: Hi Jérôme 2010/11/11 Jérôme Loyetjer...@loyet.net: If this is a normal behaviour, we should add an error at configure telling that only one SAPI is supported at once. It not, we should correct it. Did I miss something ? On Windows we have no problems in compiling multiple SAPI's using one ./configure, so I believe it is indeed a bug on the Unix build system causing this, so yeah I suppose it should be fixed. Sascha explained this briefly here: http://www.mail-archive.com/php-...@lists.php.net/msg00413.html I understand it's hard to compile mutiple SAPI (dependancies, linkage, ...). In this case, this should be clear at configure and an error message should be shown. It's not reasonable not to be able to compile CGI and apache2 sapi without any informations (like http://bugs.php.net/53271). I've made a quick patch (http://pastebin.com/jUGMtSjv) which: - move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses a config9.m4 file is to be called at configure as the last SAPI. - remove the No SAPI selected check in sapi/cgi/config.m4. To me it's not its job. It has to be done by configure. To me, the cgi sapi must be like any of the others - change the cgi sapi to be disable by default. cgi sapi will be like any other sapi (except cli), disable by default. Basically, PHP is a programming scripting language. The CLI has to be enable by default and other sapi have to be enabled by the user. - add a No SAPI selected check in configure.in, after esyscmd(./build/config-stubs sapi) (after all sapi config*.m4 files have been executed). Use CLI as default SAPI if it's not been disabled. If all SAPI and CLI have been disabled, issue the error message. - A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been called only once (all SAPI (except CLI) calls this macro). At second call, an error message telling that only one SAPI can be compiled is shown. I don't have a huge php core background but it seems (for me at least) the right way for users. hope it helps. Something called ZTS also comes to my mind.. It's not the first time ZTS comes in the discution about multiple SAPI. I've made some tests and looked into the code of the build chain, but I can't see how it's related. Maybe someone can enlight me ? thx ++ jerome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] multiple sapi (multiple bug reports)
And here's the patch: http://pecl.php.net/~jani/patches/multi-sapi.patch Note: It's not quite finished, the 'make install' might not work.. ;) --Jani 12.11.2010 2:40, Jani Taskinen kirjoitti: I'm working on an improvement on how all binaries are build thus enabling building all such in one go if one wants to. I already added a check for multiple sapi _modules_ being build, it will error out. Stay tuned, I'll post the patch once I've tested it a bit. --Jani 12.11.2010 0:03, Jérôme Loyet kirjoitti: 2010/11/11 Jani Taskinenjani.taski...@iki.fi: 11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti: Hi Jérôme 2010/11/11 Jérôme Loyetjer...@loyet.net: If this is a normal behaviour, we should add an error at configure telling that only one SAPI is supported at once. It not, we should correct it. Did I miss something ? On Windows we have no problems in compiling multiple SAPI's using one ./configure, so I believe it is indeed a bug on the Unix build system causing this, so yeah I suppose it should be fixed. Sascha explained this briefly here: http://www.mail-archive.com/php-...@lists.php.net/msg00413.html I understand it's hard to compile mutiple SAPI (dependancies, linkage, ...). In this case, this should be clear at configure and an error message should be shown. It's not reasonable not to be able to compile CGI and apache2 sapi without any informations (like http://bugs.php.net/53271). I've made a quick patch (http://pastebin.com/jUGMtSjv) which: - move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses a config9.m4 file is to be called at configure as the last SAPI. - remove the No SAPI selected check in sapi/cgi/config.m4. To me it's not its job. It has to be done by configure. To me, the cgi sapi must be like any of the others - change the cgi sapi to be disable by default. cgi sapi will be like any other sapi (except cli), disable by default. Basically, PHP is a programming scripting language. The CLI has to be enable by default and other sapi have to be enabled by the user. - add a No SAPI selected check in configure.in, after esyscmd(./build/config-stubs sapi) (after all sapi config*.m4 files have been executed). Use CLI as default SAPI if it's not been disabled. If all SAPI and CLI have been disabled, issue the error message. - A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been called only once (all SAPI (except CLI) calls this macro). At second call, an error message telling that only one SAPI can be compiled is shown. I don't have a huge php core background but it seems (for me at least) the right way for users. hope it helps. Something called ZTS also comes to my mind.. It's not the first time ZTS comes in the discution about multiple SAPI. I've made some tests and looked into the code of the build chain, but I can't see how it's related. Maybe someone can enlight me ? thx ++ jerome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Output buffering patch
24.3.2010 12:54, Lukas Kahwe Smith wrote: Hey, Could one of you write up a short RFC on this patch? Just some details about the bugs fixed, known BC breaks and (undocumented) edge case changes. This would be helpful for anyone wanting to review their code and testing as well as documentation. ROFLMAO. You can stick your RFCs where sun does not shine. I will not contribute anything as long as you're acting like some project manager. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
24.3.2010 12:02, Lukas Kahwe Smith wrote: On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. Yeah, lets. I'm fine with Derick. IIRC Rasmus also volunteered. Either one of them or both as long as Lukas and Pierre keep their hands off. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tests repository (was: Re: [PHP-DEV] PHP 6)
Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Some changes / improvements are of course needed for the run-tests.php but IIRC, someone was rewriting it already? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 12:29 PM, Hannes Magnusson wrote: On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi wrote: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? Thats actually a fairly good idea. Some tests however are not supposed to work in earlier releases, so we need to either add a new ==SKIP-VERSION== 5.2, 5.1, 5.0 Perhaps something like required min version is better. Any ideas who has been working on the improved test stuff? Or was that just a dream? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 as we know it suddenly died?
On 03/12/2010 01:40 PM, Keryx Web wrote: If the next update is quite big and breaks backwards compatibility in some ways, go directly to 7. Yes, I hope others get over the version-fobia too. :) We can't call the new (soon to be?) trunk PHP 6. Calling it 5.4 is not working either considering the bigger changes required. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 03/11/2010 11:41 PM, Christopher Jones wrote: Ilia Alshanetsky wrote: +1. I think we need we need to make HEAD a common use branch where most of the developers trees are at and current HEAD iteration is just not it. I'm +1. Jani's recent 5.3 changes should be reverted, PHP_5_4 rebranched again, and then the fixes/features merged to the new branch. I have reverted the PHP_5_3 changes. Now only thing left is renaming (moving) trunk to some branch and renaming (moving) PHP_5_4 to trunk? Or are we still at the committee state? :D As to what to do with PHP_5_2 or PHP_5_3, that should be the concern of their RMs. IMO, 5.2 is in bugfix mode, so only bugfixes go there anyway. As to 5.3, that should get into bugfix mode only as well, and all development and such concentrated in trunk. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 01:48 PM, Ulf Wendel wrote: Jani Taskinen schrieb: Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be used for testing against regressions and BC breaks, they should always be runnable using any PHP version? What you save is the work of having to update multiple branches manually. Not only update, don't forget the maintaining of them. What you risk is that not each and every test is prepared for being run with every version - although, maybe, in theory it should be. This is It should not be theory for regression tests? If new release does not pass the old tests but the old versions still do, then it's quite likely the new version is buggy? Now we have different versions of same tests in each branch (in the worst cases) and thus the behaviour might really be different between them when it should not be. Also, you may end up shipping the same huge set of tests for every PHP version regardless if all tests you ship are compatible with that version. Again, some magic should solve that - practicalities. It's still one package for all. Thus less work, less space..? :) There is one thing I fear, although it is desired to do. Many extensions link external libraries. If you throw all tests in one place and run all tests with all PHP versions, I strongly assume you'll get more reports on test failures. That is because the likeliness of someone out there running new tests designed for the latest version of an external library against an old library will increase. This part I didn't quite understand..isn't this same issue with the current situation as well? versions. I am aware how much people love BC. But there's a point where keeping BC should be left as an exercise to those asking for BC. The BC is our holy grail. And having been bitten by this myself sometimes in last 3 years, I rather be a bit anal about BC now than I was before. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
Is that new implementation in trunk already? Is it (or will it be) backwards compatible with the current one? --Jani On 03/12/2010 06:38 PM, Moriyoshi Koizumi wrote: I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Moriyoshi On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorfras...@lerdorf.com wrote: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways. So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again. The main focus here needs to be to get everyone working in the same branch. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 08:08 PM, Stanislav Malyshev wrote: Hi! Having tests in multiple branches is PITA. Hasn't anyone considered that the best way would be to move all tests into their own repository (directory..whatever :) in SVN..? Considering they are supposed to be Yes, but: some tests are version-dependant, some are not. And since we That's why we'd need to add some section to select the minimum version required to run the test. have this output match testing paradigm, it would probably keep being this way. If you're going to have branches in that SVN, how it would be different from what we have now? Considering what I said above about version check..why would you need branches in it? And what/how does it matter what the tests output if it needs to be same in any PHP version anyway..? The word repository was bad choice. The idea is just to have shared tests. Perhaps that makes it more clear? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 03/12/2010 04:15 PM, Ulf Wendel wrote: For a transition period there's likely to be more work and the number of test failures is likely to go up. That is nothing to really worry about as long as you manage to educate users that it is not a quality defect of PHP as such but a temporary matter of an different and improved testing approach. I'd say it's more work since some tests do not exists in some branch. As we might soon have quite closely related 3 branches, such differences are quite small. As trunk would have exactly same tests as PHP_5_3 has, the real differences would be only with PHP_5_2. So if we want such common tests, I think the time to do it is about now. Let's assume the worst case status quo of different versions of the same test in each branch. The one in an old branch has been written with the versions of the external library in mind that has been current when the branch was current. The one in a current branch has been written against the latest version of the external library. I continue to assume that users of the old PHP branch run rather old systems whereas users of a current PHP branch run on current systems. Therefore only few people may have tried to run the old test against the latest library or the other way around. It is just a feeling that your proposal will implicitly cause some combinations of PHP version x test x external library version to be tested that have not been checked before. So you actually fear that you'd have to fix some things in older branches too? Well, I think (hope) such cases are rare and such problems actually already exist too. Of course we can always stay with the status quo, but is that really good for PHP in general? Your one test for all proposal is likely to unveil some different versions of the same test and external library is not BC issues. That's good. But its gonna be work... IMO, such work is never a waste. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
13.3.2010 0:18, Stanislav Malyshev wrote: Hi! There are going to be some technical challenges. Some (maybe a lot) of test will need updates or rewriting. run-tests.php may need more improvements than what is already planned. Knowing this, I would still rather update run-tests.php and fix the tests, then continue to applying tests to different branches of the code base. I still have yet to hear *how* these tests are supposed to be updated, to work everywhere. It's very easy to say oh, we'll just fix them - but how exactly you're going to fix them if the test is supposed to do one thing in 5.2 and another in 5.3? Are you going to have 2 versions of What tests are you really talking about here? I thought we have regression tests in there which test that stuff does not change between versions. Such test AFAICT help us to keep stuff to work like it worked before and after some change somewhere in the related code. So there should not be any need for any updates given the tests aren't for some reason different between branches in which case they aren't really the same test anymore. Short version: if test works in 5.2 it also has to (!) work in 5.3. Otherwise the test is pointless. Can you define the case you're referring to here or are we actually talking about totally different thing? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basi
On 03/11/2010 12:50 PM, Johannes Schlüter wrote: On Thu, 2010-03-11 at 10:24 +, Jani Taskinen wrote: jani Thu, 11 Mar 2010 10:24:29 + Revision: http://svn.php.net/viewvc?view=revisionrevision=296062 Log: MFH: Improved / fixed output buffering (Michael Wallner) Yes the old code had many bugs, where most were known. But there were discussions to backport this to 5.3 before release but back then nobody was around who was willing to do the maintenance for this new code with new unknown bugs. Therefore it was left out. Merging such major changes in a released branch like 5.3 is no option. Yadda yadda, it's a bug fix. Just call next one 5.4 like it should be. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_function
On 03/11/2010 02:38 PM, Sebastian Bergmann wrote: Lukas Kahwe Smith wrote: php6 not moving forward is the root cause there So lets just close the PHP 5.2 branch and open the PHP 5.4 branch. The focus of PHP 5.4 could be the new output layer and traits (one can dream, right?). I'm not familiar enough with branching in SVN, but at least it's now quite good option. I'm all for 5.4, that's my one reason for this. The main reason was to get this work safe asap, as I'm gonna lose this laptop where it was soon enough..patching would have been an option, but we really REALLY need this discussion, hence the commit (which is still the only way to get comments anymore..) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_functi
On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote: @jani: committing to a stable branch because you are getting a new laptop is not really a convincing argument. :) Losing the one with the changes in it is. Doing patches will only cause endless headaches. Please move on, nothing to see here, it's all for GOOD anyway, fixing bugs USED to be okay in any branch. Besides, this is not end-of-world. If it is for someone, I suggest changing profession. I'd like to have branch for PHP_5_4, I'll also volunteer for RM on it. Perhaps it makes people wanting to get movement in HEAD to actually do something about it. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_functi
On 03/11/2010 06:21 PM, Scott MacVicar wrote: On Mar 11, 2010, at 10:22 AM, Jani Taskinen wrote: On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote: @jani: committing to a stable branch because you are getting a new laptop is not really a convincing argument. :) Losing the one with the changes in it is. Doing patches will only cause endless headaches. Please move on, nothing to see here, it's all for GOOD anyway, fixing bugs USED to be okay in any branch. Besides, this is not end-of-world. If it is for someone, I suggest changing profession. I'd like to have branch for PHP_5_4, I'll also volunteer for RM on it. Perhaps it makes people wanting to get movement in HEAD to actually do something about it. +1 I'm all for 5.4, I have a bunch of patches against PHP_5_3 that I want to commit such a large integer support, I couldn't develop against HEAD since it's just not usable. I think we can officially call PHP6 stalled and should move forward with 5.4 and revisit unicode support in the future. PHP_5_4 is now there. Feel free. Merging the PHP_5_3_FPM might be a good idea too. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
11.3.2010 19:22, Rasmus Lerdorf wrote: So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again. So it's just the name? Sorry, should have been more imaginative with that branch name. So what you're proposing is simply matter of renaming stuff. Rename trunk to branches/THIS_IS_LOST_CAUSE (or whatever) and PHP_5_4 to trunk. And we're a go. I really don't see reason to ditch current PHP_5_3 however, just to keep something to release stable stuff from.. The main focus here needs to be to get everyone working in the same branch. The main focus should be that we actually start working. And not wait for someone to do something miraculous on their own. I'm just sick and tired of the cloak and dagger style and secret meetings and committees. So please, do the talking openly on the mailing list, not some IRC channels. And no more wikis. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
11.3.2010 19:54, Johannes Schlüter wrote: On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote: +1 for moving trunk to a branch and moving 5.3 to trunk. not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be stable stuff (fixes) only. Guess you meant to say that, but better to be clear. How about just moving PHP_5_4 to trunk and leave (after revert..) the PHP_5_3 where it is. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] TNBT beta online at http://bugs-beta.php.net/
FYI: I installed the new bug tracker to ez1.php.net for easier testing. Feel free to test it and comment to this thread. If the DNS has not propagated yet, just add this to your hosts file: 128.39.198.38 bugs-beta.php.net Keep in mind it's NOT totally new, it's simply been cleaned up and some tiny featurettes have been added / merged from PEAR bug tracker: - Bug type (Bug, Feature/Change Request or Documentation problem) * This allows more fine-grained categorization, per pacakge - Changelog and SVN commits separate from regular comments - Patches / file attachements - Categories in DB instead of file * TODO: Online editor for categories (or s.c. pseudo packages) - Preview for reporting new bugs - Everything is UTF-8 now * f.e. http://bugs-beta.php.net/bug.php?id=51065edit=1 vs. http://bugs.php.net/bug.php?id=51065edit=1 - Something I don't remember anymore.. :D I wish this inspires more people to get involved and not waste time on the current bugs.php.net anymore. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TNBT beta online at http://bugs-beta.php.net/
22.2.2010 17:28, Richard Quadling wrote: A couple of low level things Nitpicking, are we? :D 1 - Can/should the PHP Versions include release candidates? Yes, they're outdated. This is one part that should be automated/centralized, it's enough PITA for the RMs already to remember all the places to update. I'll added note to TODO about it. 2 - Is Package affected: the right label? Yes, sort of. Remember this has origins in pear/pecl. And the ultimate goal has been to have single tracker to allow moving reports easily around. 3 - A patch file created using cvs diff -u ... cvs ? Fixed. :) And thanks for noticing. (not yet updated on the bugs-beta site, no access from home :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TNBT beta online at http://bugs-beta.php.net/
22.2.2010 19:15, Johannes Schlüter wrote: - Patches / file attachements I like the idea of calling it patch so users won't immediatly upload large big applications. Is there a size limit? No limits apart from what is set in either httpd.conf or php.ini, also, they need to be text format. Again, this is simply copy of what PEAR bug tracker has had for ages. Or at least one point had, dunno what they might be using right now. The !Quick resolve dropdown box seems to be missing. Is that intentional? For some reason it's not shown if you're not logged in. Should it be? :) Anybody working on a target milestone Feature? There's nobody working on anything except me randomly when I have had time.. Feel free. I'd rather see people improving on this than wasting time on the current horrid mess of php-bugs-web.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Execution point of session save handler on shutdown
I've used APC + custom session handler for ages without any problems. And couldn't this be fixed without such nasty hooks..? --Jani On 02/19/2010 05:54 PM, Christian Seiler wrote: Hello, [CC to pecl-dev since this is APC-related.] I have been investigating a problem occuring when using APC in combination with userspace session save handlers. This has been reported multiple times both in the APC and PHP bugtrackers, bugs related to this issue include (but are most likely not limited to): http://bugs.php.net/bug.php?id=48787 http://bugs.php.net/bug.php?id=48686 http://pecl.php.net/bugs/bug.php?id=16721 http://pecl.php.net/bugs/bug.php?id=16745 Using a debugger I have found the source of the problem. In my eyes, this is a design problem in PHP's session extension. Rationale: Currently, the session module calls php_session_flush() in its RSHUTDOWN function. This makes sure that the session handler is always called at the very end of execution. However, APC uses its RSHUTDOWN function to remove all class entries from the class table, since they are only shallow copies of memory structures of its cache and the Zend engine should not destroy the class entries by itself. The problem now occurs when the session save handler uses non-internal classes in some way. Since APC, as a dynamic extension, is always loaded AFTER the session module (always a static extension), and the module de-initialization is in reverse order, APC will unload all internal classes *before* the session save handler is executed. So when it is finally the turn of the the session save handler, the classes will no longer be present in the class table, causing the problems described above. Note that APC is not the only extension for which there is a problem with regards to de-initialization. The Spidermonkey extension destroys the current Javascript execution context in the RSHUTDOWN function, so if should any save handler use the Spidermonkey extension, it will not work. In theory, even the date extension could cause minor problems (since the default timezone is reset in RSHUTDOWN), but it gets away since it is always loaded *before* session and thus de-inititialized afterwards. I consider this to be a design problem in PHP's session extension. It tries to use the PHP engine to execute PHP code (the custom session save handler, possibly also the serialization handlers of objects etc.) during a phase where at least some other extension that may be used in that code are already de-initialized. The only reason why it got unnoticed so long is that the RSHUTDOWN code of most - but not all - extensions doesn't really have any really nasty side-effects on its use. It would not surprise me at all, however, if there were memory leaks and other strange this occurring due to this problem. My immediate fix for this problem is to make php_request_shutdown() execute the session save handler just after the userspace shutdown functions but before the RSHUTDOWN functions of the other modules. I have attached short patches to this mail for PHP 5.2, 5.3 and 6.0 that accomplish this. It's not very elegant but it is the least-invasive fix I could come up with. Not existing tests are broken in either of the three branches. Unfortunately, I was not able to create a unit test for this using core PHP alone, since all of the core extensions hide the problem. I wanted to get some feedback first. If nobody objects, however, I'll apply these patches to PHP 5.3 and PHP 6 tomorrow. As for PHP 5.2: I was extremely busy the last two months so I didn't really follow the list. Is it okay if I apply it? I do think this patch should go into the last release of PHP 5.2 (which will be used by quite a few people for a while) since this bug prevents people from using a custom session save handler in combination with APC. On a side note: For PHP6 we may think of adding an additional hook for modules that is executed at the very beginning of the shutdown phase for precisely this purpose. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
Instead of adding yet-another feature, how about fixing the bugs in the existing ones first? f.e. there is open bug related to closures, fixing that might be good idea before adding yet another way to abuse them: http://bugs.php.net/50230 And in total there are 33 scripting engine (including class/Object releated stuff) bugs open in the db of which most are even verified. Yes, it's fun to add new stuff, forget the old crap? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
On 01/19/2010 09:29 AM, Eddie Drapkin wrote: On Tue, Jan 19, 2010 at 2:14 AM, Alexey Zakhlestinindey...@gmail.com wrote: Would be nice if something like this worked too: (new Class())-method(); I was just looking at some Java code and thinking, man I wish PHP did this Funny, I was just thinking the opposite man I wish PHP never allows this :) Can of worms I say, can of worms.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debian PHP patches
On 01/17/2010 05:19 AM, Raphael Geissert wrote: Jani Taskinen wrote: 16.1.2010 20:10, Raphael Geissert wrote: Some of the other patches include: libdb_is_-ldb Why? Potentially breaks things when you assume db/ being correct place.. Do you have an example of any actual case? Do you have an example where it's actually needed? Can you tell me what exactly we are breaking? divert calls should only be used internally by autoconf and the, apparently useless, usage of them in php makes it fail to build with any other autoconf. If you remove them, things break. I don't remember right now why, but it did, Rasmus tried this already and failed. Search the mailing lists for more. His commit message is a bit weird, I think it should say 2.6x is broken in so many ways rather than 2.13: http://svn.php.net/viewvc?view=revisionrevision=291414 --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debian PHP patches
16.1.2010 20:10, Raphael Geissert wrote: Some of the other patches include: libdb_is_-ldb Why? Potentially breaks things when you assume db/ being correct place.. 115-autoconf_ftbfs.patch Hell no. You're breaking the configure again with this crap. I already reverted the idiocy once, don't even think about doing this shit again. PHP configure works properly only with autoconf-2.13 which was the last working autoconf. fix_broken_upstream_tests.patch The soap thing seems ok. But why are you disabling ext/standard/tests/general_functions/phpinfo.phpt ?? That test passes fine for me everywhere. The patch says: test suite's handling of %s is incompatible with this test Eh? bad_whatis_entries.patch Looks ok. Which should all be merged And next time, please include direct links to the patches, makes easier to follow these and comment on them. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debian PHP patches
17.1.2010 0:29, Alexey Zakhlestin wrote: On 17.01.2010, at 1:05, Gwynne Raskind wrote: On Jan 16, 2010, at 4:18 PM, Jani Taskinen wrote: 115-autoconf_ftbfs.patch Hell no. You're breaking the configure again with this crap. I already reverted the idiocy once, don't even think about doing this shit again. PHP configure works properly only with autoconf-2.13 which was the last working autoconf. Which autoconf was the last working one is a matter of opinion at this point. The Autoconf people would love for us to stop using 2.13 - the only reason it still exists is because we use it. (Or so I'm told, anyway, I don't know this for a fact firsthand.) Personally, I'd rather see PHP go to CMake. CMake does have its own host of problems, but they could be dealt with. And yes, I would volunteer to revive the CMake effort. strong +1 from me would be glad to help Strong -1000 from me, there's nothing wrong with autoconf. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 release schedule and other bits
On 01/12/2010 10:48 PM, Raphael Geissert wrote: Hello, At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. Wouldn't we all. Haven't seen any merges to the release branch since it was created..apart from some useless copyright year update. Johannes, wake up already and start doing what the RM is supposed to do: RELEASE something. And discuss the matters related to releases on internals@ and ONLY on internals@ mailing list. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 12/14/2009 10:16 PM, Jérôme Loyet wrote: Hi tony, There is several things in this patch: 1- makes log message about pool concistent. I set it to [pool %s] message. Before there where different variants: pool %s, foo (pool %s) bar [pool %s] [%s] 2- corrects some log messages which were not very meaningful for end users 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Wouldn't it make more sense to make this configurable? And thus allow people to log how they prefer.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On 12/15/2009 11:14 AM, Antony Dovgal wrote: On 15.12.2009 12:04, Jani Taskinen wrote: 3- Some log level have been switched from NOTICE to DEBUG, so that the log_file in normal operation would not be a nightmare to read (with a lot of anoying and useless messages for end users) Wouldn't it make more sense to make this configurable? And thus allow people to log how they prefer.. Surely log_level is configurable. Jerome just changed error level of some error messages to reduce the amount of notices in the log. I replied badly, I meant ALL the points in the mail. Configurable log entries, levels, etc. Not some static fprintf() stuff. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Breaking APIs for no good reason is a bad thing. (tm)
On 12/09/2009 08:37 PM, Sara Golemon wrote: Now, I'll take some blame here for not being involved over the past couple years and having not noticed this inanity sooner, but could someone explain this cluster-f? It's also bad thing to abandon code like some people tend to do. And to ignore bug reports assigned to them. Need I go on? http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_API.h?r1=268281r2=269153 [snip rant] Someone give me a good reason not to revert this. It's too late now. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
Derick Rethans wrote: On Mon, 7 Dec 2009, Ilia Alshanetsky wrote: While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. I second that; I had no clue what was going on, and I only found out about this wiki thing afterwards. Please get things back to normal like we do with 5.2. Aye. No more wikis or branches. The way 5.2 releases have been done has worked just fine 11 times. No need to reinvent the wheel here. Also, 5.3.2 should include the new output buffering code that fixes about 10 open bugs currently in the tracker. Johannes, you seem to ignore emails, so try check the bugs assigned to you. And hopefully you won't disappear again for weeks. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/branches/PHP_5_3/ext/mysql/ config.m4
1. Why are you constantly not merging stuff to HEAD? 2. Isn't this related to bug #50231 and why are you not using the proper commit message then? Hint: - Fixed bug.. It's getting quite annoying that some people (Rasmus included) tend to ignore that we have a development branch (HEAD, trunk) and play around with a sort of stable branches. You're not above anyone, please adhere to the rules like the rest of us do.. --Jani Gwynne Raskind wrote: gwynne Sat, 28 Nov 2009 21:11:39 + Revision: http://svn.php.net/viewvc?view=revisionrevision=291399 Log: socket location needs to be checked before mysqlnd in order for --with-mysql-sock to work with mysqlnd Changed paths: U php/php-src/branches/PHP_5_3/ext/mysql/config.m4 Modified: php/php-src/branches/PHP_5_3/ext/mysql/config.m4 === --- php/php-src/branches/PHP_5_3/ext/mysql/config.m42009-11-28 19:48:38 UTC (rev 291398) +++ php/php-src/branches/PHP_5_3/ext/mysql/config.m42009-11-28 21:11:39 UTC (rev 291399) @@ -53,23 +53,24 @@ [ --with-zlib-dir[=DIR] MySQL: Set the path to libz install prefix], no, no) fi +AC_MSG_CHECKING([for MySQL UNIX socket location]) +if test $PHP_MYSQL_SOCK != no test $PHP_MYSQL_SOCK != yes; then + MYSQL_SOCK=$PHP_MYSQL_SOCK + AC_DEFINE_UNQUOTED(PHP_MYSQL_UNIX_SOCK_ADDR, $MYSQL_SOCK, [ ]) + AC_MSG_RESULT([$MYSQL_SOCK]) +elif test $PHP_MYSQL = yes || test $PHP_MYSQL_SOCK = yes; then + PHP_MYSQL_SOCKET_SEARCH +else + AC_MSG_RESULT([no]) +fi + + if test $PHP_MYSQL = mysqlnd; then dnl enables build of mysqnd library PHP_MYSQLND_ENABLED=yes elif test $PHP_MYSQL != no; then - AC_MSG_CHECKING([for MySQL UNIX socket location]) - if test $PHP_MYSQL_SOCK != no test $PHP_MYSQL_SOCK != yes; then -MYSQL_SOCK=$PHP_MYSQL_SOCK -AC_DEFINE_UNQUOTED(PHP_MYSQL_UNIX_SOCK_ADDR, $MYSQL_SOCK, [ ]) -AC_MSG_RESULT([$MYSQL_SOCK]) - elif test $PHP_MYSQL = yes || test $PHP_MYSQL_SOCK = yes; then -PHP_MYSQL_SOCKET_SEARCH - else -AC_MSG_RESULT([no]) - fi - MYSQL_DIR= MYSQL_INC_DIR= -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/branches/PHP_5_3/ext/mysql/ config.m4
Rasmus Lerdorf wrote: Jani Taskinen wrote: 1. Why are you constantly not merging stuff to HEAD? 2. Isn't this related to bug #50231 and why are you not using the proper commit message then? Hint: - Fixed bug.. It's getting quite annoying that some people (Rasmus included) tend to ignore that we have a development branch (HEAD, trunk) and play around with a sort of stable branches. You're not above anyone, please adhere to the rules like the rest of us do.. The stuff I am working on right now is 5.3-only. I am going to drop 2.13 support entirely in trunk so the code is not the same. And why are you not working on trunk? Right now you're wasting my time since I can not build PHP_5_3 without changing my tools. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Backporting bypass_shell and posix_pipe() from trunk to 5.3
Gwynne Raskind wrote: Some while ago, I committed a patch to trunk which adds the shell_bypass option to proc_open() on UNIX. I'd like to backport that patch to 5.3.2, along with posix_pipe(), which helps quite a bit in using it. The patch can be found at http://pastebin.ca/raw/1691644. It's been tested and run through valgrind and the Clang analyzer. Any reason I shouldn't commit it? I tried to get it into 5.3.0 but the consensus at the time was let's get this out the door already :). -1 And buy an enter key. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf version check on trunk?
It works fine as soon as I find the typo Rasmus has done with his fixes for autoconf 2.13.. --Jani On 11/27/2009 10:56 AM, Arvind Srinivasan wrote: There was some discussion on the version (2.13 vs newer) of autoconf to use for trunk but I'm not sure whether there was any consensus. It looks like autoconf2.13 can't be used with trunk and therefore the autoconf version check inside build/buildcheck.sh needs to be updated. I get the following error when I try to configure trunk with autoconf 2.13 (this is on Ubuntu [Hardy]). autoconf2.61 works fine. Checked out revision 291346. % ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) rebuilding aclocal.m4 rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in % ./configure --prefix=/home/arvi/php-src-build --enable-debug (stuff deleted) checking whether to enable UCD SNMP hack... no checking whether to enable SOAP support... no checking whether to enable sockets support... no checking whether zend_object_value is packed... yes checking for sqlite support... yes checking whether to disable UTF-8 support in libsqlite (charset changes to ISO-8859-1)... yes checking for PDO includes... (cached) /home/arvi/php-scratch/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). checking size of char *... 4 checking for usleep... (cached) yes checking for nanosleep... (cached) yes checking for time.h... (cached) yes /configure: line 81214: syntax error at line 81217: `fi' unexpected -- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf version check on trunk?
Make that me. It's either my upgrade of libtool or combined changes by me and Rasmus. And it affects ALL branches.. :( I'm investigating this bug atm, stay tuned. --Jani On 11/27/2009 11:26 AM, Jani Taskinen wrote: It works fine as soon as I find the typo Rasmus has done with his fixes for autoconf 2.13.. --Jani On 11/27/2009 10:56 AM, Arvind Srinivasan wrote: There was some discussion on the version (2.13 vs newer) of autoconf to use for trunk but I'm not sure whether there was any consensus. It looks like autoconf2.13 can't be used with trunk and therefore the autoconf version check inside build/buildcheck.sh needs to be updated. I get the following error when I try to configure trunk with autoconf 2.13 (this is on Ubuntu [Hardy]). autoconf2.61 works fine. Checked out revision 291346. % ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) rebuilding aclocal.m4 rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in % ./configure --prefix=/home/arvi/php-src-build --enable-debug (stuff deleted) checking whether to enable UCD SNMP hack... no checking whether to enable SOAP support... no checking whether to enable sockets support... no checking whether zend_object_value is packed... yes checking for sqlite support... yes checking whether to disable UTF-8 support in libsqlite (charset changes to ISO-8859-1)... yes checking for PDO includes... (cached) /home/arvi/php-scratch/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). checking size of char *... 4 checking for usleep... (cached) yes checking for nanosleep... (cached) yes checking for time.h... (cached) yes /configure: line 81214: syntax error at line 81217: `fi' unexpected -- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf version check on trunk?
This is caused by the divert() patch Rasmus committed. Nice work. I'll try figure out how to do it properly. --Jani On 11/27/2009 01:08 PM, Jani Taskinen wrote: Make that me. It's either my upgrade of libtool or combined changes by me and Rasmus. And it affects ALL branches.. :( I'm investigating this bug atm, stay tuned. --Jani On 11/27/2009 11:26 AM, Jani Taskinen wrote: It works fine as soon as I find the typo Rasmus has done with his fixes for autoconf 2.13.. --Jani On 11/27/2009 10:56 AM, Arvind Srinivasan wrote: There was some discussion on the version (2.13 vs newer) of autoconf to use for trunk but I'm not sure whether there was any consensus. It looks like autoconf2.13 can't be used with trunk and therefore the autoconf version check inside build/buildcheck.sh needs to be updated. I get the following error when I try to configure trunk with autoconf 2.13 (this is on Ubuntu [Hardy]). autoconf2.61 works fine. Checked out revision 291346. % ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) rebuilding aclocal.m4 rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in % ./configure --prefix=/home/arvi/php-src-build --enable-debug (stuff deleted) checking whether to enable UCD SNMP hack... no checking whether to enable SOAP support... no checking whether to enable sockets support... no checking whether zend_object_value is packed... yes checking for sqlite support... yes checking whether to disable UTF-8 support in libsqlite (charset changes to ISO-8859-1)... yes checking for PDO includes... (cached) /home/arvi/php-scratch/ext checking for lemon... no configure: warning: lemon versions supported for regeneration of libsqlite parsers: 1.0 (found: none). checking size of char *... 4 checking for usleep... (cached) yes checking for nanosleep... (cached) yes checking for time.h... (cached) yes /configure: line 81214: syntax error at line 81217: `fi' unexpected -- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf version check on trunk?
On 11/27/2009 02:30 PM, Rasmus Lerdorf wrote: Jani Taskinen wrote: This is caused by the divert() patch Rasmus committed. Nice work. I'll try figure out how to do it properly. Getting rid of just the diverts in ext/standard/config.m4 fixes this for me. There is still an unrelated libtool/autoconf-2.13 issue related to finding ld though. Not sure what that is about yet. How about forget about it and stick with autoconf 2.13 which actually works and does what we need? Try ./configure --help once with the 2.6x generated one.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf version check on trunk?
As I mentioned in IRC, this is now fixed for PHP_5_2. Rasmus, please don't commit any more fixes into that branch. Experiments should be done in trunk only. :) --Jani On 11/27/2009 02:49 PM, Ilia Alshanetsky wrote: Rasmus, Do you think this is an easy fix, or do we need to go back pre-patch code for 5.2.12? The other option is to generate the build on a machine with the later autoconf, 2.59 seems to work fine. On 2009-11-27, at 7:30 AM, Rasmus Lerdorf wrote: Jani Taskinen wrote: This is caused by the divert() patch Rasmus committed. Nice work. I'll try figure out how to do it properly. Getting rid of just the diverts in ext/standard/config.m4 fixes this for me. There is still an unrelated libtool/autoconf-2.13 issue related to finding ld though. Not sure what that is about yet. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
Alexey Zakhlestin wrote: On 25.11.2009, at 13:43, Antony Dovgal wrote: On 25.11.2009 13:36, Alexey Zakhlestin wrote: Wouldn't following recommendations printed in warnings help? Sure, but only for newer autoconf versions. Which means we would break autoconf 2.13 if we follow them. Is that a problem for trunk, for example? All modern systems have newer autoconf-versions. And trunk means +1 year from now, at least All new autoconf versions suck. Only properly working version is 2.13. Please, it works, leave it alone. There are more important things to worry about. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-src
Sebastian Bergmann wrote: Rasmus Lerdorf wrote: rasmus Wed, 25 Nov 2009 01:30:06 + Revision: http://svn.php.net/viewvc?view=revisionrevision=291283 Log: Someone strap down Jani and give him a sedative please. This makes our toolchain work with the latest versions of autoconf and avoids a lot of end-user grief. Without autoconf2.13 installed, I get the following on my Ubuntu 9.10: Expected behaviour. --Jani buildconf: autoconf version 2.64 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running vcsclean for you. To avoid this, install autoconf-2.13. rebuilding aclocal.m4 rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] NEWS out of sync..
Hi Johannes, You did forget something: merging back the NEWS stuff to PHP_5_3/NEWS which has this note: ?? ??? 2009, PHP 5.3.1 # Will be merged in from branches/PHP_5_3_1 once released # Pleas add stuff under 5.3.2 The next release, can we do it like Ilia does them? The way this process was done was utter chaos. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Add INTERNALDATE to imap_append()
On 10/21/2009 01:10 AM, Nick Fortenberry wrote:
Hey everyone,
Jake Levitt and I created this patch which adds the option to set a message's
INTERNALDATE when appending it to a mail server using imap. Any chance we can
get this included into the php 5.3 and 6 development branches? The diff below
was done against the php-src/branches/PHP_5_3 branch. If you guys need me to
apply the changes to a different branch or snapshot, please let me know.
Here's the svn diff (done in my repo).. if you need something else please let
me know:
There are several problems with it. Whitespace and C++ comments being
the least. :) We have ext/date which is always there, I suggest you use
those functions to handle dates instead of flaky regexps.
--Jani
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c(revision 3405)
+++ ext/imap/php_imap.c(revision 3406)
@@ -41,6 +41,7 @@
#include ext/standard/info.h
#include ext/standard/file.h
#include ext/standard/php_smart_str.h
+#include ext/pcre/php_pcre.h
#ifdef ERROR
#undef ERROR
@@ -118,6 +119,7 @@
ZEND_ARG_INFO(0, folder)
ZEND_ARG_INFO(0, message)
ZEND_ARG_INFO(0, options)
+ZEND_ARG_INFO(0, date)
ZEND_END_ARG_INFO()
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_num_msg, 0, 0, 1)
@@ -1270,20 +1272,43 @@
PHP_FUNCTION(imap_append)
{
zval *streamind;
-char *folder, *message, *flags = NULL;
-int folder_len, message_len, flags_len = 0;
+char *folder, *message, *date = NULL, *flags = NULL;
+int folder_len, message_len, date_len = 0, flags_len = 0;
pils *imap_le_struct;
STRING st;
-if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
rss|s,streamind,folder,folder_len,message,message_len,flags,flags_len)
== FAILURE) {
+if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
rss|ss,streamind,folder,folder_len,message,message_len,flags,flags_len,date,date_len)
== FAILURE) {
return;
}
+char* regex = /[
0-3][0-9]-((Jan)|(Feb)|(Mar)|(Apr)|(May)|(Jun)|(Jul)|(Aug)|(Sep)|(Oct)|(Nov)|(Dec))-[0-9]{4}
[0-2][0-9]:[0-5][0-9]:[0-5][0-9] [+-][0-9]{4}/;
+int regex_len = strlen(regex);
+pcre_cache_entry *pce;//Compiled regex
+zval *subpats = NULL;//Parts (not used)
+long regex_flags = 0;//Flags (not used)
+long start_offset = 0;//Start offset
(not used)
+int global = 0;
+
+if (date) {
+//Make sure the given date string matches the RFC specified
format
+if ((pce = pcre_get_compiled_regex_cache(regex, regex_len
TSRMLS_CC)) == NULL) {
+RETURN_FALSE;
+}
+
+php_pcre_match_impl(pce, date, date_len, return_value,
subpats, global,
+0, regex_flags, start_offset TSRMLS_CC);
+
+if (!Z_LVAL_P(return_value)) {
+php_error_docref(NULL TSRMLS_CC, E_WARNING, internal date
not correctly formatted);
+date = NULL;
+}
+}
+
ZEND_FETCH_RESOURCE(imap_le_struct, pils *,streamind, -1, imap,
le_imap);
INIT (st, mail_string, (void *) message, message_len);
-if (mail_append_full(imap_le_struct-imap_stream, folder, (flags ? flags :
NIL), NIL,st)) {
+if (mail_append_full(imap_le_struct-imap_stream, folder, (flags ? flags :
NIL), (date ? date : NIL),st)) {
RETURN_TRUE;
} else {
RETURN_FALSE;
Thanks,
- Nick Fortenberry
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Add INTERNALDATE to imap_append()
1. Top-posting is considered evil.
2. Look harder, timelib_* has several functions for this, be creative..
3. Tabs instead of spaces, NO C++ comments!
--Jani
On 10/21/2009 06:37 PM, Nick Fortenberry wrote:
Hey Jani,
We looked through the date library but it doesn't look like there are any
functions to verify that a date is in a certain format. Unless we are
mistaken, it looks like the only way to verify this would be to use a regex.
Also, we read through CODING_STANDARDS and it said to be generous with
whitespace and brackets. Were you referring to something in particular with
regards to whitespace?
Thanks,
Nick
-Original Message-
From: Jani Taskinenjani.taski...@iki.fi
Sent: Wednesday, October 21, 2009 2:55am
To: Nick Fortenberryn...@mailtrust.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: Add INTERNALDATE to imap_append()
On 10/21/2009 01:10 AM, Nick Fortenberry wrote:
Hey everyone,
Jake Levitt and I created this patch which adds the option to set a message's
INTERNALDATE when appending it to a mail server using imap. Any chance we can
get this included into the php 5.3 and 6 development branches? The diff below
was done against the php-src/branches/PHP_5_3 branch. If you guys need me to
apply the changes to a different branch or snapshot, please let me know.
Here's the svn diff (done in my repo).. if you need something else please let
me know:
There are several problems with it. Whitespace and C++ comments being
the least. :) We have ext/date which is always there, I suggest you use
those functions to handle dates instead of flaky regexps.
--Jani
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c(revision 3405)
+++ ext/imap/php_imap.c(revision 3406)
@@ -41,6 +41,7 @@
#include ext/standard/info.h
#include ext/standard/file.h
#include ext/standard/php_smart_str.h
+#include ext/pcre/php_pcre.h
#ifdef ERROR
#undef ERROR
@@ -118,6 +119,7 @@
ZEND_ARG_INFO(0, folder)
ZEND_ARG_INFO(0, message)
ZEND_ARG_INFO(0, options)
+ZEND_ARG_INFO(0, date)
ZEND_END_ARG_INFO()
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_num_msg, 0, 0, 1)
@@ -1270,20 +1272,43 @@
PHP_FUNCTION(imap_append)
{
zval *streamind;
-char *folder, *message, *flags = NULL;
-int folder_len, message_len, flags_len = 0;
+char *folder, *message, *date = NULL, *flags = NULL;
+int folder_len, message_len, date_len = 0, flags_len = 0;
pils *imap_le_struct;
STRING st;
-if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
rss|s,streamind,folder,folder_len,message,message_len,flags,flags_len)
== FAILURE) {
+if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
rss|ss,streamind,folder,folder_len,message,message_len,flags,flags_len,date,date_len)
== FAILURE) {
return;
}
+char* regex = /[
0-3][0-9]-((Jan)|(Feb)|(Mar)|(Apr)|(May)|(Jun)|(Jul)|(Aug)|(Sep)|(Oct)|(Nov)|(Dec))-[0-9]{4}
[0-2][0-9]:[0-5][0-9]:[0-5][0-9] [+-][0-9]{4}/;
+int regex_len = strlen(regex);
+pcre_cache_entry *pce;//Compiled regex
+zval *subpats = NULL;//Parts (not used)
+long regex_flags = 0;//Flags (not used)
+long start_offset = 0;//Start offset
(not used)
+int global = 0;
+
+if (date) {
+//Make sure the given date string matches the RFC specified
format
+if ((pce = pcre_get_compiled_regex_cache(regex, regex_len
TSRMLS_CC)) == NULL) {
+RETURN_FALSE;
+}
+
+php_pcre_match_impl(pce, date, date_len, return_value,
subpats, global,
+0, regex_flags, start_offset TSRMLS_CC);
+
+if (!Z_LVAL_P(return_value)) {
+php_error_docref(NULL TSRMLS_CC, E_WARNING, internal date
not correctly formatted);
+date = NULL;
+}
+}
+
ZEND_FETCH_RESOURCE(imap_le_struct, pils *,streamind, -1, imap,
le_imap);
INIT (st, mail_string, (void *) message, message_len);
-if (mail_append_full(imap_le_struct-imap_stream, folder, (flags ? flags :
NIL), NIL,st)) {
+if (mail_append_full(imap_le_struct-imap_stream, folder, (flags ? flags :
NIL), (date ? date : NIL),st)) {
RETURN_TRUE;
} else {
RETURN_FALSE;
Thanks,
- Nick Fortenberry
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Allow array_change_key_case to support ucfirst and lcfirst
Matthew Fonda wrote: Hi All, I came across a situation where I had to make the first character of an arrays keys uppercase, and found the array_change_key_case function, but noticed it only supported CASE_UPPER and CASE_LOWER. Attached is a patch to also add support for CASE_LCFIRST and CASE_UCFIRST. The patch is against PHP_5_3. I wasn't sure which branch I should write it for--let me know if it should be against another branch. This is my first patch submission so any comments are appreciated. New stuff - HEAD only (aka trunk :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Functions that fails on large files
This is the current patch for bug #27792: http://www.php.net/~wez/lfs.diff --Jani On 09/13/2009 01:20 PM, X Ryl wrote: The patch in 27792 doesn't work, but the one in 48886 does (from my own tests) 2009/9/13 Laurent Léonardlaur...@open-minds.org Hi, What about that bug ? http://bugs.php.net/bug.php?id=27792 I see there is a patch here on this related bug report : http://bugs.php.net/bug.php?id=48886 Do you plan to fix the issue ? Thank you, -- Laurent Léonard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mb_string.func_overload has secretly been changed from PERDIR to SYSTEM
On 09/10/2009 04:46 PM, Tony Marston wrote: You are missing the point. I'm not trying to set the encoding for any HTML output as that is handled differently. What I am concerned about is the func_overload option which, ever since PHP 4.2.0, we have been able to turn on or off using an htaccess directive on a PERDIR basis. Although neither the documentation nor the release notes have been changed the PERDIR option has disappeared and it is now set either on or off for the entire system and cannot be modified with any htaccess or ini_set directive. So if func_overload is turned on, how do I turn it off? If it is turned off how do I turn it on? Considering that phpMyAdmin does not like it to be turned on, this is not a trivial point. Simply doing a search in the bug system would have revealed the current status of this: http://bugs.php.net/bug.php?id=49189edit=1 The documentation team just hasn't got around changing the docs yet and adding a note about it there. Feel free to provide a patch or forever be silent. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [sapi] PHP-FPM (FastCGI Process Manager), by Andrei Nigmatulin - upstream Y/n?
On 09/09/2009 03:01 AM, Rasmus Lerdorf wrote: This has been discussed before. See: http://news.php.net/php.internals/44476 http://news.php.net/php.internals/44480 http://news.php.net/php.internals/44484 http://news.php.net/php.internals/44485 Basically it comes down to figuring out whether to extend the existing FastCGI SAPI to support the process management in FPM, or add it as a separate SAPI. As separate SAPI, wouldn't it duplicate a LOT of code, basically for nothing? I'd rather see the good parts of this merged into the one-and-only sapi/cgi/ code instead of creating yet another SAPI nobody maintains for real. --Jani -Rasmus dreamcat four wrote: Hi! We have today been asked by Debian and Ubuntu Maintainers to merge our code up to PHP repository. They have stated that they want to see the fpm sapi variant officially supported. It would be nice to hear what you guy's official decision would be about something like this. Here are some details about the FPM Project, and it's current status: Andrei has done very clean, pristine code since forking the fcgi-sapi and moving it forward in the 0.602. I have been involved recently in this simply as a packager for the new 0.6 line of FPM Project. We maintain ourselves as a seperate project on launchpad, and have not submitting any code to you guys (PHP). But since this request from debian/ubuntu, i guess we need for some type of upstream sync or import process. We are versioned in bzr and github. ## Autoconf This project relies upon its own versions of the autoconf toolset to generate its `./configure` script. To use autoconf, then run `./build-autotools` which will install it locally in the directory. If `./build-autotools` fails we have more information in autoconf.markdown. ## Build process Compilation is pretty straightforward and hassle-free. The make process can be described as: 1) Compile the php sources into object files in the php build directory 2) Compile the fpm sources into object files in the fpm build directory 3) Link all the php object file with these fpm object file together 4) Output: Static php5 binary, which is php base and using the fpm's version of fcgi-SAPI as frontend Fpm is mixed into php at the link-level. This de-couples the fpm sources, making the process manager part somewhat less sensitive to changes in the php project. PHP-FPM is derived from the fcgi-sapi. We no longer patch directly onto php-maintained files. Instead there are 3 similar counterpart files from sapi/cgi and fpm's sapi are periodically synced to them. Libevent library is included for the process management. ## Licence Fpm has a very minimal licence. Fpm-sapi is a php license. The bundled Libevent library is OpenBSD. Please Contact Andrei Nigmatulin regarding any further licensing questions. You should otherwise credit Andrei Nigmatulin as the author of /fpm sources. ## Compatibility Fpm 0.6.3+ is coming soon for the following versions of php: php-5.2.10+ (ready) php-5.3.any (definitely coming this week) php-6.0 /trunk (may be this week also, if no hitch) The script in our src tree 'generate-fpm-patch' is a possible way to sync changes. Or perhaps there's a better way to get from bzr into a subtree as svn. The project's sub-tree is; config/ libevent/ man/ src/ src/fpm/ src/sapi/ Would we be required to change the layout of our project's subtree? And then which directory can it exist? a) ext/fpm/ b) fpm/ c) sapi/fpm/ ? Again, please any thoughts / discussion welcome. Best regards, dreamcat4 dreamc...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [sapi] PHP-FPM (FastCGI Process Manager), by Andrei Nigmatulin - upstream Y/n?
On 09/09/2009 08:55 AM, sean finney wrote: On Wed, Sep 09, 2009 at 03:42:44AM +0100, dreamcat four wrote: Not sure about bundling libevent though - does it have to be bundled? Don't know. Libevent is frozen in there and a couple of files were modified with references back into the fpm headers. The Libevent was updated recently anyway, so its a pretty recent version. just FYI this will also be problematic. as some of the other php devs are probably well aware (hi pierre!), we have a pretty strict policy against using embedded libraries, even more so for embedded libraries that have been locally modified. Yeah, NO THANKS. We have enough of unmaintained code already. Since you want this fpm thing into upstream PHP releases, why not make the changes into libevent go upstream as well and then reconsider bundling, merging, etc. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [sapi] PHP-FPM (FastCGI Process Manager), by Andrei Nigmatulin - upstream Y/n?
On 09/09/2009 10:53 AM, Stanislav Malyshev wrote: As separate SAPI, wouldn't it duplicate a LOT of code, basically for nothing? I'd rather see the good parts of this merged into the one-and-only sapi/cgi/ code instead of creating yet another SAPI nobody maintains for real. If the code will be really the same exactly, then maybe it can be just reused (e.g. functions, etc.)? If not, then somewhat similar code I don't think is a problem if it's maintained, and if it's not then better have unmaintaned separate SAPI then unmaintained pieces of code inside of one of most used SAPIs :) In general, I'd consider changing sapi/cgi adding new potentially unstable hode rather high-risk, unless it can be very well isolated. sapi/cgi runs quite a lot of code... Very good point. And I did consider only merging the _good_ parts of this thing. I haven't had time to check the code yet at all (quite busy at work right now) but there are some stuff it does we haven't generally considered the job of PHP before. The list of them is here: http://php-fpm.org/What_is_PHP-FPM --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/zend_object_handlers.c branches/PHP_5_3/NEWS branches/PHP_5_3/main/fopen_wrappers.c branches/PHP_5_3/sapi/cgi/cgi_main.c trunk/main/fop
On 09/07/2009 09:25 AM, Dmitry Stogov wrote: Hi, I'm wondered why the shebang line support was removed from scanner. Because it didn't make any sense for other SAPIs. You could ask Ilia more about it: - r273178 | iliaa | 2009-01-09 19:21:12 +0200 (Fri, 09 Jan 2009) | 4 lines MFH: Corrected fix for bug #46844 to only trigger on the 1st line of CLI opened files. Note that going back to this solution requires extra open() and fstat() syscalls in case the requested file already stored in opcode cache. It might be a visible slowdown for FastCGI sapi. Any ideas how to avoid it without adding this thing into the scanner? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shebang skipping in 5.3.0
It's very legit to use with CGI since you might not be able to run PHP any other way. So this is definately a bug, CGI should handle it the same as CLI. The bug report clearly explains it too: http://bugs.php.net/bug.php?id=49182 --Jani Andi Gutmans wrote: Shebang is for command line scripts (php-cli). It does not make sense to support it for Web server scripts. It just adds unnecessary code/complexity to that code base. Removing the support from php-cgi was really a remnant of the old days when cli and cgi were the same SAPI. I think we are better off this way. Andi -Original Message- From: Joey Smith [mailto:j...@joeysmith.com] Sent: Friday, September 04, 2009 1:35 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] shebang skipping in 5.3.0 I definitely had the wrong changeset - sorry, Nuno. :) Looks like maybe 273177 is the problem child. http://tinyurl.com/lewcft On Fri, Sep 04, 2009 at 09:25:52AM +0100, Scott MacVicar wrote: On 4 Sep 2009, at 09:16, Joey Smith j...@joeysmith.com wrote: I can understand not having the 'shebang skipping' code in both the SAPI *and* the scanner, but we probably need to have it in at least ONE of them. :) Per his email[1] almost a year ago, Dmitry removed the shebang line check from sapi/cgi/cgi_main.c in changeset 264153, saying: Removed shebang line check from CGI sapi (it is checked by scanner) In http://tinyurl.com/me8528 (changeset 262275), nlopess removed the code from the scanner. Oops? What's the problem your having? The skip code is still there just in a different bit. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shebang skipping in 5.3.0
You obviously don't understand at all what this is used for. Consider the case where you can't change webserver's configs. Or that you want to quickly test different PHP versions. What would be easier than simply switching the version in the shebang line? Quite legitimate and useful to me. And this has NOTHING to do with CLI. --Jani Pierre Joye wrote: I'm not totally convinced by this argument. CGI is definitively a different SAPI than CLI and can behave differently. It was a problem before when we had only one command for both CLI and CGI, but that's not the case anymore. We should better document CLI and recommend to always install it shell usage is planed (and distros should install it by default as well). On Sat, Sep 5, 2009 at 1:47 PM, Jani Taskinenjani.taski...@sci.fi wrote: It's very legit to use with CGI since you might not be able to run PHP any other way. So this is definately a bug, CGI should handle it the same as CLI. The bug report clearly explains it too: http://bugs.php.net/bug.php?id=49182 --Jani Andi Gutmans wrote: Shebang is for command line scripts (php-cli). It does not make sense to support it for Web server scripts. It just adds unnecessary code/complexity to that code base. Removing the support from php-cgi was really a remnant of the old days when cli and cgi were the same SAPI. I think we are better off this way. Andi -Original Message- From: Joey Smith [mailto:j...@joeysmith.com] Sent: Friday, September 04, 2009 1:35 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] shebang skipping in 5.3.0 I definitely had the wrong changeset - sorry, Nuno. :) Looks like maybe 273177 is the problem child. http://tinyurl.com/lewcft On Fri, Sep 04, 2009 at 09:25:52AM +0100, Scott MacVicar wrote: On 4 Sep 2009, at 09:16, Joey Smith j...@joeysmith.com wrote: I can understand not having the 'shebang skipping' code in both the SAPI *and* the scanner, but we probably need to have it in at least ONE of them. :) Per his email[1] almost a year ago, Dmitry removed the shebang line check from sapi/cgi/cgi_main.c in changeset 264153, saying: Removed shebang line check from CGI sapi (it is checked by scanner) In http://tinyurl.com/me8528 (changeset 262275), nlopess removed the code from the scanner. Oops? What's the problem your having? The skip code is still there just in a different bit. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shebang skipping in 5.3.0
Pierre Joye wrote: On Sat, Sep 5, 2009 at 2:48 PM, Jani Taskinenjani.taski...@sci.fi wrote: You obviously don't understand at all what this is used for. Consider the case where you can't change webserver's configs. Or that you want to quickly test different PHP versions. What would be easier than simply switching the version in the shebang line? Quite legitimate and useful to me. And this has NOTHING to do with CLI. I do and I still don't agree. This edge case is not worth the effort to maintain this feature for CGI. BC. Need I say more? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shebang skipping in 5.3.0
Marco Tabini wrote: It would be really nice if everyone could consider that the other do understand what is being discussed but actually disagree. The question was actually: is it worth the effort? Who is seriously using CGI (not meaning fastcgi) with php these days? On shared hosts, CGI is often the only way to have your own custom version of PHP. I don't know if that's relevant to this conversation, though :-) It's quite relevant. It's actually one of the most important things I tried to explain Pierre already. And yes, people still use CGI these days. Not all of them have their own webservers running they can configure however they wish. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Timezone for php_error_log.
Errors output from MINIT can not and will not ever have any other timezone than what is the system's timezone. If you're reporting a bug, please do it at http://bugs.php.net/. Anyways the code in sqlsrv is pretty horrible. I'd cleanup that mess first. Unless of course you can reproduce same under something else than windows and with any other extensions. --Jani On 09/03/2009 02:10 PM, Richard Quadling wrote: Hi. I've been playing with the MS SQL Server driver (https://sqlsrvphp.svn.codeplex.com/svn). Using this code (editing it to work with the default WinResrc.h rather than the winres.h it is currently asking for) ... AND ... turning on the logging via the ini file (as I was playing I just wanted to see what was logged) ... sqlsrv.LogSeverity= -1 sqlsrv.LogSubsystems = -1 sqlsrv.WarningsReturnAsErrors = On The log file shows entries like ... [03-Sep-2009 11:55:11] PHP Warning: PHP Startup: Unable to load dynamic library 'C:/PHP5/ext\php_curl.dll' - The operating system cannot run %1. in Unknown on line 0 [03-Sep-2009 11:55:11] PHP_MINIT_FUNCTION for php_sqlsrv: entering [03-Sep-2009 10:55:11] sqlsrv: entering rinit [03-Sep-2009 10:55:11] sqlsrv.WarningsReturnAsErrors = On [03-Sep-2009 10:55:11] sqlsrv.LogSeverity = 255 [03-Sep-2009 10:55:11] sqlsrv.LogSubsystems = 255 [03-Sep-2009 10:55:11] sqlsrv: entering rshutdown In changing /* $Id: main.c 286478 2009-07-29 00:17:10Z stas $ */ ... error_time_str = php_format_date(d-M-Y H:i:s, 11, error_time, php_during_module_startup() TSRMLS_CC); to error_time_str = php_format_date(d-M-Y H:i:s e, 13, error_time, php_during_module_startup() TSRMLS_CC); the log file now looks like ... [03-Sep-2009 11:55:11 Europe/London] PHP Warning: PHP Startup: Unable to load dynamic library 'C:/PHP5/ext\php_curl.dll' - The operating system cannot run %1. in Unknown on line 0[03-Sep-2009 11:55:11 Europe/London] PHP_MINIT_FUNCTION for php_sqlsrv: entering [03-Sep-2009 10:55:11 UTC] sqlsrv: entering rinit [03-Sep-2009 10:55:11 UTC] sqlsrv.WarningsReturnAsErrors = On [03-Sep-2009 10:55:11 UTC] sqlsrv.LogSeverity = 255 [03-Sep-2009 10:55:11 UTC] sqlsrv.LogSubsystems = 255 [03-Sep-2009 10:55:11 UTC] sqlsrv: entering rshutdown I'm not too sure what's going on. I think it has something to do with php_during_module_startup(), but I can't work out when the response to this function will ever change as it returns a static int value. The above logs were created using date.timezone=Europe/London and calling ... php -m This gets a little odder when I use ... php -d date.timezone=Europe/Berlin -m The output is now ... [03-Sep-2009 12:05:40 Europe/London] PHP Warning: PHP Startup: Unable to load dynamic library 'C:/PHP5/ext\php_curl.dll' - The operating system cannot run %1. in Unknown on line 0 [03-Sep-2009 13:05:41 Europe/Berlin] PHP_MINIT_FUNCTION for php_sqlsrv: entering [03-Sep-2009 11:05:41 UTC] sqlsrv: entering rinit [03-Sep-2009 11:05:41 UTC] sqlsrv.WarningsReturnAsErrors = On [03-Sep-2009 11:05:41 UTC] sqlsrv.LogSeverity = 255 [03-Sep-2009 11:05:41 UTC] sqlsrv.LogSubsystems = 255 [03-Sep-2009 11:05:41 UTC] sqlsrv: entering rshutdown Don't worry about the specifics of the curl error - this isn't my issue. I would suggest that the datetime extension needs to be loaded before the curl library request as I assume this will get the timezone I've supplied (Europe/Berlin). I'm just not sure about the sqlsrv timezone though at all. Why isn't this Europe/something rather than UTC? Regards, Richard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really going to 5.3.1RC1
On 08/29/2009 05:33 PM, Johannes Schlüter wrote: Hi, I thought I sent the warning out on thursday but can't find it in my internals folder therefore the notice: We certainly should get 5.3.1 rolling and therefore I'm planning RC1 on Tuesday evening European time I'm not t used to subversion therefore I'd like some comments about this procedure: 1) Monday evening branch of a release branch owned by me $ svn cp branches/PHP_5_3 branches/php_5_3_1 Question A: using php as in our tags or PHP as in our branches? Question B: can svn merge be used to get changes from PHP_5_3 or is a manual merge better? 2) Tuesday: Change the version $ vi branches/php_5_3_1/main/php_version.h etc. 3) making the branch a tag $ svn mv branches/php_5_3_1 tags/php_5_3_1 4) merge the tag into the PHP_5_3 branch $ cd branches/PHP_5_3 svn merge ../tags/php_5_3_1 The idea would be that the release appears in the branch's history and nothing is being lost Question: Does that make any sense? 5) Change the version to RC2-dev $ vi branches/PHP_5_3/main/php_version.h etc. I don't understand why you are merging things back and forth like that. Just keep it simple: PHP_5_3 is open for any commits, php_5_3_1 is only for commits you pick into it. And only do manual merge. Otherwise you won't be merging what you want for real. ;) Don't mess with version in PHP_5_3, only in php_5_3_1 where you create the RCs from. And please, no more tags, those are totally useless in SVN world, IMO. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] silent startup errors msg about deprecated (or other) warnings
On 08/31/2009 12:06 AM, Pierre Joye wrote: Hi, While trying to fix some tests, I found that display_startup_errors is ignored by some startup errors like deprecated ini settings. Using: php -d display_startup_errors=0 -d safe_mode=1 foo.php See also bug #49362 (http://bugs.php.net/bug.php?id=49362) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 08/25/2009 12:42 AM, Stanislav Malyshev wrote: Hi! Quite boring to read this thread where two persons argue about something abstract. Stas, can you give a real life example where your patch is necessary..? Any code where you either use @ or error_reporting which is not -1 would benefit from it by not processing errors that go nowhere. I just looked at Zend Framework - with is pretty clean with regard to E_NOTICE/E_STRICT problems - and @ is used in dozens of classes around. The speedup would be probably not very big for whole RL application, but it's a 10-line patch, and little things help too. Just wondering why nobody hasn't suggested the obvious (?) alternative yet: Why not fix error_reporting to work like one expects. As in: If an error level isn't in it, then nothing happens. Adding an extra option to do that seems a bit overkill.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote: Hi! Just wondering why nobody hasn't suggested the obvious (?) alternative yet: Why not fix error_reporting to work like one expects. As in: If an error level isn't in it, then nothing happens. Adding an extra option to do that seems a bit overkill.. Because it would break other funcions (namely, $php_errormsg, error handlers, etc.) which may be used by some. Well, not necessarily. How doesn't your patch break them? Just do the same but without adding new option. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
Daniel Convissor wrote: Hello Jani: On Tue, Aug 25, 2009 at 11:11:19AM +0300, Jani Taskinen wrote: On 08/25/2009 10:35 AM, Stanislav Malyshev wrote: Because it would break other funcions (namely, $php_errormsg, error handlers, etc.) which may be used by some. Well, not necessarily. How doesn't your patch break them? Just do the same but without adding new option. The patch allows setting reporting to E_ALL while using the mask to kill just E_STRICT. Sorry, I just don't get it. If the mask thing kills some level..what's the point in enabling it in the first place? And IIRC, E_STRICT is not part of E_ALL.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
Quite boring to read this thread where two persons argue about something abstract. Stas, can you give a real life example where your patch is necessary..? --Jani Stanislav Malyshev wrote: Hi! Unless your code is ridden or if you prefer filled with @ and/or errors the speed improvement would be next to impossible to measure since you'd be literally saving microseconds. You'd need to have a Microsecond here, microsecond there - this stuff adds up. And 2-3 mallocs of substantial size (IIRC some messages are long enough so emalloc caches do not apply) plus whole printf ordeal - even twice in some cases - are not that small change, especially if it could happen repeatedly. Of course it alone won't make you 50% speedup, but even 0.5% here and 0.5% there add up. BTW, if you benchmark only this thing (yes, I know, it's not realistic :) the difference is very, very measurable - error reporting slows down operation with ignored error 3-4 times. I think if I proposed an improvement that would speed up certain set of opcodes 3 times that'd be worth having, not? to make a reliably measurable difference. More over, if the user defines an error handler, which many applications, frameworks, etc... do then your improvement is next to invisible in between the overhead of executing PHP code to process the error. The thing is you would be in control of which errors too feed to the error handler and which not to. That's exactly the point - giving you the tools to control it. Including tools to deal with noisy code the way you like - which may be your way, my way or any way in between. If you don't care - default changes nothing, but if you do, you have the means to make it run faster. Vast majority of E_NOTICEs are not fixed not because people don't want You are still focused on one particular case of E_NOTICE. It's not (only) what's it about, it's bigger. set to ignore those errors. And E_NOTICES btw often could've let people know about security faults before they were abused, such as uninitialized variables and array keys that could be injected via register_globals, extract() function, etc... Yes, yes - if only they were actually *seen* by anybody. The case we discuss here is when they *are not* seen anyway. So I don't see how your argument applies. Your argument is about entirely different thing which I do not argue with you about - that some warning should not be disabled/hidden. I agree with you. But some OTHER warnings should be, and that's the case I want to fix. Stas, my biggest issue is that you are making this configurable value that makes this open to abuse, rather then using 0 as default and matching the error message creation to error reporting settings. It can be done too, but not having other configuration will disable some scenarios when you don't want the error to go through usual reporting mechanisms but want debugger/monitoring system still see it. I understand that if we designed error_reporting from scratch maybe we'd just say one switch for everybody, but since we already have people that are used to having current system, I made it as flexible as possible. If people around here think it's too flexible I could just make it on/off (i.e. same as -1/0 with current patch), it's trivial. I just wanted to start with max flexibility. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd as a shared extension ?
On 08/17/2009 08:12 PM, Remi Collet wrote: Hi, Building 5.3.1 snapshot with options --with-mysql=shared,mysqlnd --with-mysqli=shared,mysqlnd --with-pdo-mysql=shared,mysqlnd create 3 .so files, ok. But mysqlnd extension still build as static within php core. It's not an extension. Is it a way to build mysqlnd as a shared extension ? No, it's not an extension. Don't find any option and .m4 file set this extension as static (changing this result in a .so which cannot be load) My goal will be to provides both solutions (libmysql and mysqlnd) to be able to quickly switch from one to the other (for tests / benchmark) Not possible. Any idea / solution ? No idea or solutions. P.S. main question is probably, should we use mysqlnd under linux ? If you want to use experimental stuff then yes. Otherwise not. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.1 RC 1
Top poster! And Windows only bugs are not critical. That error_log crash alone should have caused an immediate release weeks ago.. --Jani On 08/07/2009 01:06 AM, Pierre Joye wrote: hi Johannes, I do not have the chance to match this planning. I'll be back from holidays on Monday and will work on some of the critical issues we have to fix from Wednesday only. The initial idea was to do 5.3.1 in September not in August. I wonder what's the reasons behind this change (as it drastically changes the initial planing...)? Besides the usual we have many fixes, let do a release :). Besides that it would be nice to avoid to release two versions on the same day, even for a RC. We already have limited QA resources, no need to put more work on us :). Cheers, -- Pierre 2009/8/6 Johannes Schlüterjohan...@php.net: Hi, following Ilia's notice I want to give a heads-up for 5.3.1 RC1, too. We have quite many fixes in SVN and the packaging script was successful in my test. I want to try to keep it along the same schedule as Ilia with 5.2 so we can keep commit limitations - in case we need them - as limited as possible. This means: The aim is to have RC1 next week thursday and if all goes well a final release by the end of August. The biggest item I want to see fixed is the Sparc memory alignment bug (#48668) which currently gives lots of trouble when using PHP on SPARC, David is working on that and hopes to get a fix till RC1 done. Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 08/03/2009 07:52 AM, dan...@zoltak.com wrote:
Jani Taskinen wrote:
[snip]
You obviously do not have the correct sources then.
Try get them directly using SVN:
# svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/
And if those don't work either, you need to provide a GDB backtrace,
the
strace is useless for this. Also make sure you configure PHP using
--enable-debug !!
I have compile both apache and php using debug and run gdb with the
following result:
Obviously you haven't compiled using --enable-debug OR most likely are
not using the compiled libphp5.so. Check your phpinfo() that you
actually use the one you compiled first..
--Jani
#0 0x7f3e96df82eb in ?? () from /usr/lib64/apache2/modules/libphp5.so
#1 0x7f3e96dfb085 in zend_hash_find () from
/usr/lib64/apache2/modules/libphp5.so
#2 0x7f3e96d9229c in custom_open_base_check () from
/usr/lib64/apache2/modules/libphp5.so
#3 0x7f3e96d90c56 in php_check_specific_open_basedir () from
/usr/lib64/apache2/modules/libphp5.so
#4 0x7f3e96d9107f in php_check_open_basedir_ex () from
/usr/lib64/apache2/modules/libphp5.so
#5 0x7f3e96d90fd4 in php_check_open_basedir () from
/usr/lib64/apache2/modules/libphp5.so
#6 0x7f3e96d86adb in ?? () from /usr/lib64/apache2/modules/libphp5.so
#7 0x7f3e96e05346 in zend_alter_ini_entry_ex () from
/usr/lib64/apache2/modules/libphp5.so
#8 0x7f3e96e0511c in zend_alter_ini_entry () from
/usr/lib64/apache2/modules/libphp5.so
#9 0x7f3e96e77ded in apply_config () from
/usr/lib64/apache2/modules/libphp5.so
#10 0x7f3e96e77033 in ?? () from /usr/lib64/apache2/modules/libphp5.so
#11 0x00436633 in ap_run_handler ()
#12 0x00439511 in ap_invoke_handler ()
#13 0x004430b4 in ap_process_request ()
#14 0x00440706 in ?? ()
#15 0x0043ceb4 in ap_run_process_connection ()
#16 0x00446db7 in ?? ()
#17 0x00447012 in ?? ()
#18 0x004470ac in ?? ()
#19 0x00447cc8 in ap_mpm_run ()
#20 0x00425ab3 in main ()
The function custom_open_base_check() contains:
// Document root from Zend (pointer to pointer)
zval **document_root = NULL;
// Make sure DOCUMENT_ROOT is accessible from the global vars
if (!PG(http_globals)[TRACK_VARS_SERVER] ||
zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]-value.ht,
DOCUMENT_ROOT,
sizeof(DOCUMENT_ROOT), (void **) document_root) == FAILURE) {
// Unable to find DOCUMENT_ROOT
php_error_docref(NULL TSRMLS_CC, E_WARNING, fopen_wrapper_patch:
DOCUMENT_ROOT variable
is not set, cannot determine document root.);
// Can't check the document root - fail
return -1;
}
It crashing when its looking up the DOCUMENT_ROOT in the zend_hash_find.
This only occurs when the following is defined in an htaccess and with
the custom function in place:
[snip]
php_value error_log '/home/st/stu/studio1.com.au/www/logs/php_err.log'
Is it safe to access the DOCUMENT_ROOT this way at this point in the
code? If not is there an alternative or is there something wrong
somewhere else in the code?
If you could guide me on how to produce the necessary output to debug it
would be much appreciated.
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 08/03/2009 02:52 PM, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: On 08/03/2009 07:52 AM, dan...@zoltak.com wrote: Jani Taskinen wrote: [snip] Obviously you haven't compiled using --enable-debug OR most likely are not using the compiled libphp5.so. Check your phpinfo() that you actually use the one you compiled first.. --Jani Here is the correct backtrace. Hope it can bring some insight. Well, this is using PHP 5.2.10. And you were supposed to test the snapshot. How about the backtrace using latest PHP_5_2 checkout? --Jani #0 0x7f51031d12eb in _zend_is_inconsistent (ht=0x5a5a5a5a5a5a5a5a, file=0x7f510350bf58 /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c, line=875) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c:53 #1 0x7f51031d4085 in zend_hash_find (ht=0x5a5a5a5a5a5a5a5a, arKey=0x7f51034eee80 DOCUMENT_ROOT, nKeyLength=14, pData=0x7fff10fff068) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c:875 #2 0x7f510316b29c in custom_open_base_check (basedir=0x3dd0f40 VIRTUAL_DOCUMENT_ROOT, resolved_name=0x7fff11003170 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:709 #3 0x7f5103169c56 in php_check_specific_open_basedir (basedir=0x3dd0f40 VIRTUAL_DOCUMENT_ROOT, path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:118 #4 0x7f510316a07f in php_check_open_basedir_ex (path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, warn=1) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:249 #5 0x7f5103169fd4 in php_check_open_basedir (path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:225 #6 0x7f510315fadb in OnUpdateErrorLog (entry=0x3bff8d0, new_value=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, mh_arg1=0x68, mh_arg2=0x7f510386cc20, mh_arg3=0x0, stage=32) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/main.c:317 #7 0x7f51031de346 in zend_alter_ini_entry_ex (name=0x3e30680 error_log, name_length=10, new_value=0x3e20910 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32, force_change=0) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_ini.c:293 #8 0x7f51031de11c in zend_alter_ini_entry (name=0x3e30680 error_log, name_length=10, new_value=0x3e20910 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_ini.c:248 #9 0x7f5103250ded in apply_config (dummy=0x3e21aa0) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/sapi/apache2handler/apache_config.c:195 #10 0x7f5103250033 in php_handler (r=0x3e262c8) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/sapi/apache2handler/sapi_apache2.c:531 #11 0x004369fc in ap_run_handler (r=0x3e262c8) at config.c:157 #12 0x00439aa4 in ap_invoke_handler (r=0x3e262c8) at config.c:372 #13 0x0044370c in ap_process_request (r=0x3e262c8) at http_request.c:282 #14 0x00440d85 in ap_process_http_connection (c=0x3e12138) at http_core.c:190 #15 0x0043d3f8 in ap_run_process_connection (c=0x3e12138) at connection.c:43 #16 0x0043d4ca in ap_process_connection (c=0x3e12138, csd=0x3e11f48) at connection.c:178 #17 0x00447814 in child_main (child_num_arg=value optimized out) at prefork.c:650 #18 0x004479a0 in make_child (s=0x66f850, slot=99) at prefork.c:746 #19 0x00447a00 in startup_children (number_to_start=1) at prefork.c:764 #20 0x00447ed7 in ap_mpm_run (_pconf=0x66a138, plog=value optimized out, s=value optimized out) at prefork.c:985 #21 0x00426039 in main (argc=27, argv=0x7fff11004b48) at main.c:740 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 08/03/2009 03:19 PM, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: Well, this is using PHP 5.2.10. And you were supposed to test the snapshot. How about the backtrace using latest PHP_5_2 checkout? I downloaded the latest snap and tar.bz2 it in the php-5.2.10 folder so I could compiled it using the php-5.2.10 ebuild file in gentoo. Isn't the latest snap based off the SVN? Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Dan Zoltak wrote: Jani Taskinen wrote: [snip] There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. I've download and tested the latest snap (php5.2-200908020630) and I am still having the same issue. I have performed an strace with the following result: You obviously do not have the correct sources then. Try get them directly using SVN: # svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ And if those don't work either, you need to provide a GDB backtrace, the strace is useless for this. Also make sure you configure PHP using --enable-debug !! --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Rasmus Lerdorf wrote: Jani Taskinen wrote: Dan Zoltak wrote: Jani Taskinen wrote: [snip] There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. I've download and tested the latest snap (php5.2-200908020630) and I am still having the same issue. I have performed an strace with the following result: You obviously do not have the correct sources then. Try get them directly using SVN: # svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ And if those don't work either, you need to provide a GDB backtrace, the strace is useless for this. Also make sure you configure PHP using --enable-debug !! Jani, if you mean the fix for bug #48880, then that doesn't apply here. That was 5.3/6 only because it was in the new code that lets you tighten the open_basedir restrictions at runtime. I don't see any 5.2 fopen_wrappers.c changes for the past many months. No, I was thinking the issue here was fixed by fixing bug #48247. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 07/31/2009 03:10 AM, dan...@zoltak.com wrote: [snip] The above code has been works fine in PHP 5.2.6. In PHP 5.2.10 it works except when an .htaccess is defined with the following: --BEGIN SNIP .htaccess-- php_value error_log '/home/st/stu/studio1.com.au/www/logs/php_err.log' --END SNIP-- There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU
I'm just waiting for you to just commit it.. :) --Jani On 07/29/2009 12:08 PM, Moriyoshi Koizumi wrote: Aren't there any interests on this? If you think PHP 6 is gonna cover all of the functionality that allegedly-cruft mbstring currently provides, that is almost wrong :-p Moriyoshi On Tue, Jul 28, 2009 at 5:41 PM, Moriyoshi Koizumim...@mozo.jp wrote: I set up a RFC page for this in wiki.php.net. Here it goes: http://wiki.php.net/rfc/altmbstring Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt
Gwynne Raskind wrote: On Jul 27, 2009, at 6:31 PM, Takeshi Abe wrote: Just to be sure, is there any consensus on this? I thought I should use svn merge. README.SVN-RULES says 1. All changes should first go to trunk and then get merged from trunk (aka MFH'ed) to all other relevant branches. which I've been following so far. That document is outdated. It's now (strongly) preferred that you use one of the various methods for multi-branch commits available in SVN, using merge or a sparse checkout. It's only sparse checkout that works for us. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)
Dmitry Stogov wrote: David Zülke wrote: On 28.07.2009, at 13:32, Dmitry Stogov wrote: Hi David, I took only a quick look, but I like the patch. In case it doesn't break any tests, it should be committed at least into HEAD. I agree to commit it into 5.3 too, but RMs take the final decision. The only thing I didn't understood - why win32/php_stdint.h is needed. Ah, yes, that's probably an oversight. Good catch. The headers were copy-pasted from some ext/date file :) Another thing that just occured to me is that we now have a dependency on ext/date; I think I had trouble compiling ext/soap as a standalone extension like this. Must check again. Any hints? I think ext/date can't be removed or compiled as shared extension. If it's the case, the only problem may be with unexported symbols. Just try to compile/test it as shared extension on Linux and Windows. ext/date is not an extension, it's part of core, just like ext/standard so you shouldn't have any problems with it. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn checkout suggestion
Can I suggest you not to suggest any other VCS from now on? If you like some VCS better, just keep that info to yourself, no need to spam the mailing lists about it. --Jani On 07/20/2009 01:38 PM, Arnold Daniels wrote: Hi, Can I suggest having a look at GIT (http://git-scm.com). It has some mayor advantages above SVN. The most important one is that it's a distributed version control system. Let's say Rasmus leads a team working on a new feature in PHP to switch from .ini to .yaml files for configuration. With GIT it's not needed that the whole team has commit access to the main GIT repository. Rasmus can checkout PHP to his own server. The team can checkout and commit to Rasmus' server. Rasmus still update the checkout of his server to get the changes made in the main PHP repo. When Rasmus is satisfied that the feature works, he (and only he) can commit it to the main repo. If you look at the linux kernel, you see that there is a whole hierarchy. There are lieutenants who are responsible for a certain part of the kernel. The lieutenant has got a small team working on that part. Each team member, may have a team of his own working on a specific feature. I would think a structure like this would work very nicely for PHP. - Arnold On Thu, 2009-07-16 at 18:09 -0500, Greg Beaver wrote: Rasmus Lerdorf wrote: One of the benefits of svn is that we can do cross-branch commit pretty easily now and thus avoid multiple similar commits with annoying MFH/MFB commit log messages that are hard to track. Please don't attempt to check out all of php/php-src or pecl. I made the mistake of checking out all of pecl and it was 3.4G because you get copies of the code for every tag and branch and we have a bunch. In order to do this better, I think the best way is to use the sparse directory feature documented here: http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html snip Rasmus this is brilliant. You should add this to the manual for posterity in your new shiny checkout of awesomeness. :) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for Bug #
On 07/15/2009 08:49 PM, David Zülke wrote: Hi there, attached are patches for http://bugs.php.net/48929. Big kudos to Tjerk Anne and Arnaud, this forking HTTP server stuff for testing the stream wrapper is genius. Ehem..was this ever committed? And don't you have svn access yourself anyway? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH for bug 48774
On 07/18/2009 07:03 PM, Sriram Natarajan wrote: Jani Taskinen wrote: Sriram Natarajan wrote: Hi I was looking into CR: 48774(http://bugs.php.net/bug.php?id=48774thanks=3) and was hoping if some one can kindly review this patch. This patch does address the SEGV issue reported in the bug. Can this be applied to PHP 5.3 and PHP 5.2 as well ? Fix your whitespace first. We use tabs only in .c files.. Please find the updated patch below As you seem to have your own svn account, I guess you can commit it yourself now? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH for bug 48774
Sriram Natarajan wrote:
Hi
I was looking into CR:
48774(http://bugs.php.net/bug.php?id=48774thanks=3) and was hoping if
some one can kindly review this patch. This patch does address the SEGV
issue reported in the bug. Can this be applied to PHP 5.3 and PHP 5.2 as
well ?
Index: ext/curl/interface.c
===
--- ext/curl/interface.c(revision 284171)
+++ ext/curl/interface.c(working copy)
@@ -1328,6 +1328,7 @@
{
php_curl*ch;
CURL*cp;
+ zval*clone;
Fix your whitespace first. We use tabs only in .c files..
--Jani
char*url = NULL;
int url_len = 0;
@@ -1353,6 +1354,9 @@
ch-uses = 0;
+ MAKE_STD_ZVAL(clone);
+ ch-clone = clone;
+
curl_easy_setopt(ch-cp, CURLOPT_NOPROGRESS,1);
curl_easy_setopt(ch-cp, CURLOPT_VERBOSE, 0);
curl_easy_setopt(ch-cp, CURLOPT_ERRORBUFFER, ch-err.str);
@@ -1448,6 +1452,10 @@
zend_llist_copy(dupch-to_free.slist, ch-to_free.slist);
zend_llist_copy(dupch-to_free.post, ch-to_free.post);
+ /* Keep track of cloned copies to avoid invoking curl
destructors for every clone */
+ Z_ADDREF_P(ch-clone);
+ dupch-clone = ch-clone;
+
ZEND_REGISTER_RESOURCE(return_value, dupch, le_curl);
dupch-id = Z_LVAL_P(return_value);
}
@@ -2298,9 +2306,20 @@
#if LIBCURL_VERSION_NUM 0x071101
zend_llist_clean(ch-to_free.str);
#endif
- zend_llist_clean(ch-to_free.slist);
- zend_llist_clean(ch-to_free.post);
+ /* cURL destructors should be invoked only by last curl handle */
+ if (Z_REFCOUNT_P(ch-clone) = 1) {
+ zend_llist_clean(ch-to_free.slist);
+ zend_llist_clean(ch-to_free.post);
+ zval_ptr_dtor(ch-clone);
+ } else {
+ Z_DELREF_P(ch-clone);
+ ch-to_free.slist.dtor = NULL;
+ ch-to_free.post.dtor = NULL;
+ zend_llist_clean(ch-to_free.slist);
+ zend_llist_clean(ch-to_free.post);
+ }
+
if (ch-handlers-write-buf.len 0) {
smart_str_free(ch-handlers-write-buf);
}
Index: ext/curl/tests/curl_copy_handle_basic_007.phpt
===
--- ext/curl/tests/curl_copy_handle_basic_007.phpt (revision 0)
+++ ext/curl/tests/curl_copy_handle_basic_007.phpt (revision 0)
@@ -0,0 +1,44 @@
+--TEST--
+Test curl_copy_handle() with simple POST
+--SKIPIF--
+?php if (!extension_loaded(curl) || false ===
getenv('PHP_CURL_HTTP_REMOTE_SERVER')) print skip; ?
+--FILE--
+?php
+ $host = getenv('PHP_CURL_HTTP_REMOTE_SERVER');
+
+ echo '*** Testing curl copy handle with simple POST using array as
arguments ***' . \n;
+
+ $url = {$host}/get.php?test=getpost;
+ $ch = curl_init();
+
+ ob_start(); // start output buffering
+ curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
+ curl_setopt($ch, CURLOPT_POST, 1);
+ curl_setopt($ch, CURLOPT_POSTFIELDS, array(Hello = World, Foo
= Bar, Person = John Doe));
+ curl_setopt($ch, CURLOPT_URL, $url); //set the url we want to use
+ + $copy = curl_copy_handle($ch);
+ curl_close($ch);
+
+ $curl_content = curl_exec($copy);
+ curl_close($copy);
+
+ var_dump( $curl_content );
+?
+===DONE===
+--EXPECTF--
+*** Testing curl copy handle with simple POST using array as arguments ***
+string(163) array(1) {
+ [test]=
+ string(7) getpost
+}
+array(3) {
+ [Hello]=
+ string(5) World
+ [Foo]=
+ string(3) Bar
+ [Person]=
+ string(8) John Doe
+}
+
+===DONE===
Index: ext/curl/php_curl.h
===
--- ext/curl/php_curl.h (revision 284171)
+++ ext/curl/php_curl.h (working copy)
@@ -139,6 +139,7 @@
long id;
unsigned int uses;
zend_boolin_callback;
+ zval *clone;
} php_curl;
typedef struct {
Index: NEWS
===
--- NEWS(revision 284171)
+++ NEWS(working copy)
@@ -32,6 +32,8 @@
(markril at hotmail dot com, Pierre)
- Fixed bug #38091 (Mail() does not use FQDN when sending SMTP helo).
(Kalle, Rick Yorgason)
+- Fixed bug #48774 (SIGSEGVs when using curl_copy_handle()).
+ (Sriram Natarajan)
30 Jun 2009, PHP 5.3.0
- Upgraded bundled PCRE to version 7.9. (Nuno)
thanks
sriram
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] svn checkout suggestion
On 07/17/2009 01:24 AM, Jani Taskinen wrote: Rasmus Lerdorf wrote: One of the benefits of svn is that we can do cross-branch commit pretty easily now and thus avoid multiple similar commits with annoying MFH/MFB commit log messages that are hard to track. I did a commit today on all 3 branches and it worked fine except for the fact that no commit email was sent anywhere. I sent Gwynne a note about it, but so that everyone knows too, don't commit anything like that until this is fixed.. Uh..nevermind. Apparently the commit had failed (and I didn't notice it) and thus never happened.. :D --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #47481
On 07/14/2009 05:38 AM, Herman Radtke wrote: This bug only exists in PHP 5.x. The unicode support in PHP 6 takes care of it already, but I added a PHP 6 version of the test case as well. Committed. I fixed the test to work in all branches. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming php-cvs to php-svn ?
Uwe Schindler wrote: Or just to something more generic like php-commits@ ? The same with zend-commits? Only php-commits@ is necessary since there is no separate Zend stuff anymore..? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] svn checkout suggestion
Rasmus Lerdorf wrote: One of the benefits of svn is that we can do cross-branch commit pretty easily now and thus avoid multiple similar commits with annoying MFH/MFB commit log messages that are hard to track. I did a commit today on all 3 branches and it worked fine except for the fact that no commit email was sent anywhere. I sent Gwynne a note about it, but so that everyone knows too, don't commit anything like that until this is fixed.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug tracker planning
Sriram Natarajan wrote: Hi bug tracking system also need the ability to mark a current bug as duplicate . Currently, all those bugs are marked as 'Bogus'. Also, it would be nice if we can have the ability to capture related bugs together. - Sriram Again: DO NOT TOP POST!! And we're not adding anymore statuses. Status is irrelevant for bug being related to something or not. --Jani Philip Olson wrote: The bug system today works fine but improvements are being made. I've gone through the lists and details from past attempts and will list ideas here. Please do not vote, but if a particular item appears like a bad idea then please explain. Or, discuss additional (or modified) ideas that will be useful to the PHP project. The new system[1] is based off the pear.php.net bug system (via Jani), which long ago was a fork of our current (bugs.php.net). Because of this, some of these items are already available via the pear geeks. The plan is to have one bug tracker that includes PEAR+PECL+Core+GTK+Etc. It's also planning to go live after Stage #1 is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are working on this project. Soonish a test system will be setup for all to break. Yes, this really is happening. Most people like the current system because it's simple, and I don't foresee this changing. First stage: - Cleanup code (in progress) - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) - Package/Type separation : Packages (like extensions) and Bug Types (like feature requests) are separate (done) - Defined/Documented permissions : For example, so we all know if a random person can comment on a bogus bug - Preview button, instead of only submit (almost done) - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, and associated links - Importing - Testing Second stage: - Additional history : When a bug was opened/closed etc. Currently we don't log this except in emails - Reclassification : Discuss how we handle this, like should old/new lists both receive emails? - Consider different captcha (like reCaptcha) for anonymous users - Voting : Do we use or care about this? Improve? - nofeedback improvements : People assume this means closed, when it does not Third stage: - Subscriptions : Allow people to subscribe to RSS and/or receive emails per bug/package - Tagging : Allow people to optionally attach tags to bugs - IRC integration : Allow bot integration to an IRC channel, like a #php.bugs resurrection - Optional milestones (in pearweb today) - Integrate with VCS. Research this, KISS. Ex. A commit containing PHP Bug #42 automagically appends info to the bugs db - Befriend systems like http://bts-link.alioth.debian.org/ - OpenID support, see also http://wiki.php.net/ideas/phpnetauth - Username finder for the 'assigned' boxes, see also http://people.php.net/ And as always, additional volunteers are welcome. Regards, Philip [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug tracker planning
Sriram Natarajan wrote: Jani Taskinen wrote: Please don't top post! And what you ask for is already there. --Jani Sriram Natarajan kirjoitti: Hi I very much miss the ability to add my email address to the bugs that I am interested in. This used to allow to me to track its progress. I wasn't not sure, if that is what you meant within Subscriptions.. - sriram Jani if I am not mistaken, only CVS account holder currently can a email address to a bug. I am requesting for the ability to add email address for folks who don't have this privilege. This allows other people who ran into the same issue to be able to monitor the status of the bug as well. You are mistaken and haven't read this thread at all. We are not talking about the current tracker at http://bugs.php.net/ here but the new stuff which is based on http://pear.php.net/bugs/bug.php?id=377edit=1 (that url as example to show you that anyone can really subscribe to any bug..and that same is also in the new code..) --Jani - Sriram -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Conversion Complete
Gwynne Raskind kirjoitti: The conversion from CVS to SVN is complete. CVS read AND write access has been completely disabled. SVN is now up and running, however *we Why is CVS read access disabled? I had some patches brewing in my checkouts and getting them out now is kinda PITA.. Also checking that the conversion actually worked would be easier when one could compare the logs and such.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug tracker planning
Please don't top post! And what you ask for is already there. --Jani Sriram Natarajan kirjoitti: Hi I very much miss the ability to add my email address to the bugs that I am interested in. This used to allow to me to track its progress. I wasn't not sure, if that is what you meant within Subscriptions.. - sriram Philip Olson wrote: The bug system today works fine but improvements are being made. I've gone through the lists and details from past attempts and will list ideas here. Please do not vote, but if a particular item appears like a bad idea then please explain. Or, discuss additional (or modified) ideas that will be useful to the PHP project. The new system[1] is based off the pear.php.net bug system (via Jani), which long ago was a fork of our current (bugs.php.net). Because of this, some of these items are already available via the pear geeks. The plan is to have one bug tracker that includes PEAR+PECL+Core+GTK+Etc. It's also planning to go live after Stage #1 is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are working on this project. Soonish a test system will be setup for all to break. Yes, this really is happening. Most people like the current system because it's simple, and I don't foresee this changing. First stage: - Cleanup code (in progress) - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) - Package/Type separation : Packages (like extensions) and Bug Types (like feature requests) are separate (done) - Defined/Documented permissions : For example, so we all know if a random person can comment on a bogus bug - Preview button, instead of only submit (almost done) - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, and associated links - Importing - Testing Second stage: - Additional history : When a bug was opened/closed etc. Currently we don't log this except in emails - Reclassification : Discuss how we handle this, like should old/new lists both receive emails? - Consider different captcha (like reCaptcha) for anonymous users - Voting : Do we use or care about this? Improve? - nofeedback improvements : People assume this means closed, when it does not Third stage: - Subscriptions : Allow people to subscribe to RSS and/or receive emails per bug/package - Tagging : Allow people to optionally attach tags to bugs - IRC integration : Allow bot integration to an IRC channel, like a #php.bugs resurrection - Optional milestones (in pearweb today) - Integrate with VCS. Research this, KISS. Ex. A commit containing PHP Bug #42 automagically appends info to the bugs db - Befriend systems like http://bts-link.alioth.debian.org/ - OpenID support, see also http://wiki.php.net/ideas/phpnetauth - Username finder for the 'assigned' boxes, see also http://people.php.net/ And as always, additional volunteers are welcome. Regards, Philip [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: On 7-Jul-09, at 8:43 PM, Rasmus Lerdorf wrote: That doesn't really change the timing, especially since you said you have been using it for 2 years. Why pick the week after the 5.3 release to propose it for 5.3? It makes very little sense to me, and I think consensus is building that we aren't going to add this to 5.3. I wish I had time to post the patch sooner, but timing was such that it was not an option. Plus people have tried to post the same functionality before there was patch from Hannes back in 2006, a full RFC by Fellipe in 2008 (with patch) and now my attempt in 2009. After some discussions at the developer meeting in Chicago and seeing that there was a substantial interest in the feature I've cleaned up the code and posted the patch. I think half the people who voted +1 didn't realize you were seriously thinking of pushing it into 5.3 Well, its only Tuesday there is plenty of time for people to change their mind (like some already have). Agreeably its a major decisions and I think everyone would agree it should not hinge on 1-2 votes either way, there has to be a substantial let it in consensus for it to go in. Like I said earlier on IRC, I'm +1 for this in 5.4 if that ever happens. Otherwise it's gotta be PHP 6. Or just spork. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Jani Taskinen wrote: Ilia Alshanetsky wrote: On 7-Jul-09, at 8:43 PM, Rasmus Lerdorf wrote: That doesn't really change the timing, especially since you said you have been using it for 2 years. Why pick the week after the 5.3 release to propose it for 5.3? It makes very little sense to me, and I think consensus is building that we aren't going to add this to 5.3. I wish I had time to post the patch sooner, but timing was such that it was not an option. Plus people have tried to post the same functionality before there was patch from Hannes back in 2006, a full RFC by Fellipe in 2008 (with patch) and now my attempt in 2009. After some discussions at the developer meeting in Chicago and seeing that there was a substantial interest in the feature I've cleaned up the code and posted the patch. I think half the people who voted +1 didn't realize you were seriously thinking of pushing it into 5.3 Well, its only Tuesday there is plenty of time for people to change their mind (like some already have). Agreeably its a major decisions and I think everyone would agree it should not hinge on 1-2 votes either way, there has to be a substantial let it in consensus for it to go in. Like I said earlier on IRC, I'm +1 for this in 5.4 if that ever happens. Otherwise it's gotta be PHP 6. Or just spork. :) --Jani One more thing: It seems there is no reason not to simply commit it to HEAD. That's the development branch, if the thing isn't good, it can be removed / modified / etc. This voting is really whether it should be merged or not.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
