Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/standard/html.c ext/standard/tests/strings/bug44703.phpt ext/standard/tests/strings/get_html_translation_table_basic1.phpt ext/standard/tests/strings/ge
On 26.03.2010, at 13:39, Johannes Schlüter wrote: On Tue, 2010-03-23 at 18:08 +, Rasmus Lerdorf wrote: rasmus Tue, 23 Mar 2010 18:08:06 + Revision: http://svn.php.net/viewvc?view=revisionrevision=296685 Log: Switch default_charset, if not specified, from ISO-8859-1 to UTF-8 I have been wanting to make this change for years, but there is a small chance of BC issues, so it shouldn't go into a minor release. I in my world this isn't just a small chance of a break. Over here every application has to deal with non-ASCII characters (äöüßÄÖÜ). Many average applications don't set the encoding, most don't care. With the environments using more and more Utf-8 (operating system environments, editor defaults, ...) the change is good but it is no small thing but will cause trouble for many users having iso-8859-1 texts in their database and getting broken pages after the upgrade and we should advise users to mind their encodings! Fixing applications is easy, getting the knowledge to our users is hard. I had the same feeling when Rasmus mentioned his change. I think its a good chance, but I am not sure if we should include it in a 5.4 if that is the version name for the next release. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] svn: /php/php-src/branches/
On 12.03.2010, at 14:21, Pierre Joye wrote: On Fri, Mar 12, 2010 at 12:29 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Fri, Mar 12, 2010 at 10:57, Pierre Joye pierre@gmail.com wrote: On Thu, Mar 11, 2010 at 5:09 PM, Jani Taskinen j...@php.net wrote: jani Thu, 11 Mar 2010 16:09:37 + Revision: http://svn.php.net/viewvc?view=revisionrevision=296076 Log: Hello PHP 5.4, open for all new stuff. Instead of persisting into doing whatever you feel or want, what are you waiting for to revert your commits as requested numerous times already? The numerous requests for moving trunk to branches/UNICODE_EXPERIMENT is the reason. There no reason to kill this branch. As soon as trunk has been moved, this branch will become the next trunk/ Confusions, wrong messages, bad suggestions, no reason to hurry up without a real plan, etc. Those are all very good reasons not to do it this way, especially not because someone had yet another crazy day. PHP really does not need such events, as our reputations about releases managements is slowly getting better... Because no decision has been made. Jani is creating facts without basis. Furthermore normal development is continuing on the branches we decided to have. Now there is suddenly a 5.4. The point in time when we branch off a new trunk shouldn't be Jani deciding this because he is pissed off because there are open OB bugs. So I am all for getting excited again about moving php forward, but lets not loose our head over this. Jani has done the first step in cleaning up his mess. The next step is removing _his_ 5_4 branch. I do not see this as negotiable and its not about proofing a point. Its simply not sensible to keep this branch and confuse the hell out of everyone. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] svn: /php/php-src/branches/
On 12.03.2010, at 14:52, Jani Taskinen wrote: On 03/12/2010 03:43 PM, Lukas Kahwe Smith wrote: Because no decision has been made. Jani is creating facts without basis. Furthermore normal development is continuing on the branches we decided to have. Now there is suddenly a 5.4. The point in time when we branch off a new trunk shouldn't be Jani deciding this because he is pissed off because there are open OB bugs. Where the hell did you imagine that one? I'm not pissed at or about anything. We can continue with the status quo for all I care, but don't start deleting other people's work just because you don't like me. Jani this has nothing to do with liking or not liking you. Actually I usually get along just fine with you. I still remember that you were the first core guy I ever had direct contact with and I also appreciate still how fast you fixed that IMAP bug I reported back then. But I did not appreciate the actions you took yesterday. I totally that current trunk is a stumbling block. But I cannot agree with you first committing something to 5_3 which the RM specifically said not to merge and then creating a branch without consent. Again there are commits going into 5_3 now which are for example not being merged in 5_4 atm and why should people do this? We can find a more sensible time point for the merge, more importantly we first need to make a decision on dropping current trunk into a branch or not. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] svn: /php/php-src/branches/
On 12.03.2010, at 15:27, Andrey Hristov wrote: Lukas, Lukas Kahwe Smith wrote: On 12.03.2010, at 14:52, Jani Taskinen wrote: On 03/12/2010 03:43 PM, Lukas Kahwe Smith wrote: Because no decision has been made. Jani is creating facts without basis. Furthermore normal development is continuing on the branches we decided to have. Now there is suddenly a 5.4. The point in time when we branch off a new trunk shouldn't be Jani deciding this because he is pissed off because there are open OB bugs. Where the hell did you imagine that one? I'm not pissed at or about anything. We can continue with the status quo for all I care, but don't start deleting other people's work just because you don't like me. Jani this has nothing to do with liking or not liking you. Actually I usually get along just fine with you. I still remember that you were the first core guy I ever had direct contact with and I also appreciate still how fast you fixed that IMAP bug I reported back then. But I did not appreciate the actions you took yesterday. I totally that current trunk is a stumbling block. But I cannot agree with you first committing something to 5_3 which the RM specifically said not to merge and then creating a branch without consent. Again there are commits going into 5_3 now which are for example not being merged in 5_4 atm and why should people do this? We can find a more sensible time point for the merge, more importantly we first need to make a decision on dropping current trunk into a branch or not. well, when nobody was doing nothing because nobody did not want to be the first one to do something Jani decided to do something and stir the soup. Sometimes you need a shock to the system to restart it. heh .. lets just say a few others have chosen to go a path that isnt about just causing chaos to force a decision. then again this make these people (i am one of them (*)) back stabbers. anyways .. if this is the perception .. thats its ok to commit something into a stable branch that was specifically said to be left out and as a reaction creating a new branch (instead of at least first reverting) when people call you out, then uhm .. then nevermind. so why dont we just shut down this list and just send each other mails via commit log messages? imho jani's commit access should be revoked until we have sorted out our release plan for the future, because he has shown that he has no patience to respect other people's opinions and so we can alleviate him of doing stupid things to release his anxiety. but i guess i am just being a rule loving german here .. or am i just the only one with enough guts to say this? regards, Lukas Kahwe Smith m...@pooteeweet.org (*) i was actually talking to various people since this weekend to be able to present a substantiated argument to move trunk to a branch and copy 5_3 to trunk and also be able to present something of a vision for moving forward. interestingly enough other people were also just in the process to do the same. now this would have taken a week or two longer .. but imho it would have been a cleaner way to do things .. or of course you can also say that jani is the honest and direct guy and those others are just political schemers. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] svn: php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/standard/proc_open.c branches/PHP_5_3/ext/standard/proc_open.h branches/PHP_5_3/ext/standard/tests/general_functions/proc_ope
On 20.07.2009, at 21:36, Nuno Lopes wrote: On Mon, Jul 20, 2009 at 12:19 PM, Jani Taskinenj...@php.net wrote: Excuse me but where/when was it agreed that this new feature can go into PHP_5_3? I thought it was supposed to go HEAD only.. It should not go in 5.3, Nuno please revert. Why not? Should we wait 2 years to implement these kind of little things? Or even to implement new things? Especially in a web-oriented language like PHP, you cannot afford to release new stuff only once in 2 years. Nuno, It was decided that 5.3.1 would be reserved for bug fixes only for now. Then again when this was put into place we feared we might need a quick 5.3.1 to fix big issues in 5.3.0. It doesnt seem like this is the case and so 5.3.1 has not been scheduled yet nor is there a pressing need to do so. Anyways, since I am no longer RM .. its not my call to make. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / php.ini-development php.ini-production
On 30.06.2009, at 11:57, Hannes Magnusson wrote: On Tue, Jun 30, 2009 at 11:15, Jani Taskinenjani.taski...@sci.fi wrote: Hannes Magnusson wrote: bjori Tue Jun 30 08:49:05 2009 UTC Modified files: /php-srcphp.ini-production php.ini-development Log: MFB5.3: Add missing ini entries (Mikko) http://cvs.php.net/viewvc.cgi/php-src/php.ini-production?r1=1.12r2=1.13diff_format=u Index: php-src/php.ini-production diff -u php-src/php.ini-production:1.12 php-src/php.ini-production: 1.13 --- php-src/php.ini-production:1.12 Sun Jun 28 17:55:36 2009 +++ php-src/php.ini-production Tue Jun 30 08:49:05 2009 @@ -641,7 +641,7 @@ ; Data Handling ; ; -; Note - track_vars is ALWAYS enabled as of PHP 4.0.3 +; Note - track_vars is ALWAYS enabled Isn't that note kinda useless anyway. I don't even know what that track_vars is supposed to be..some PHP 3 thing? Good point. We should probably remove it before 5.3.1 You mean marking it deprecated and removing it in PHP 6.0? Seems sensible to me. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / php.ini-development php.ini-production
On 02.07.2009, at 14:48, Derick Rethans wrote: On Thu, 2 Jul 2009, Lukas Kahwe Smith wrote: On 30.06.2009, at 11:57, Hannes Magnusson wrote: On Tue, Jun 30, 2009 at 11:15, Jani Taskinenjani.taski...@sci.fi wrote: Hannes Magnusson wrote: bjori Tue Jun 30 08:49:05 2009 UTC Modified files: /php-srcphp.ini-production php.ini-development Log: MFB5.3: Add missing ini entries (Mikko) http://cvs.php.net/viewvc.cgi/php-src/php.ini-production?r1=1.12r2=1.13diff_format=u Index: php-src/php.ini-production diff -u php-src/php.ini-production:1.12 php-src/php.ini- production:1.13 --- php-src/php.ini-production:1.12 Sun Jun 28 17:55:36 2009 +++ php-src/php.ini-production Tue Jun 30 08:49:05 2009 @@ -641,7 +641,7 @@ ; Data Handling ; ; -; Note - track_vars is ALWAYS enabled as of PHP 4.0.3 +; Note - track_vars is ALWAYS enabled Isn't that note kinda useless anyway. I don't even know what that track_vars is supposed to be..some PHP 3 thing? Good point. We should probably remove it before 5.3.1 You mean marking it deprecated and removing it in PHP 6.0? Seems sensible to me. This setting is *long* gone, it can just be removed. Ah, great. I got confused by the docs: http://ch.php.net/manual/en/ini.core.php#ini.track-vars Note that as of PHP 4.0.3, track_vars is always turned on. The entry on http://ch.php.net/manual/en/ini.list.php is a bit cleaer: track_vars 1 PHP_INI_ALL Removed in PHP 4.0.3. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/phar/phar pharcommand.inc
On 25.06.2009, at 00:12, Greg Beaver wrote: cellog Wed Jun 24 22:12:47 2009 UTC Modified files: (Branch: PHP_5_3) /php-src NEWS /php-src/ext/phar/phar pharcommand.inc Log: fix slightly unclear error message in generation of phar.phar This doesnt need to be merged to HEAD? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /main php_open_temporary_file.c
On 24.06.2009, at 18:34, Ilia Alshanetsky wrote:
Will keep in mind for the future, do you want me to revert the change?
The patch looks safe. However if you would have asked before
commiting, Johannes would have said no, since its simply not critical
enough to bring any risk to the release process at this point. Then
again, this fixes a bug, its in CVS, so it seems like children finger
slapping to ask for a revert.
We have to trust that people do not intentionally go against what we
ask and we have to also hope that people realize that this is a
sensitive for the 5_3 branch and then check posts from the RM's before
committing. I guess we should maybe define some subject prefix to give
such posts additional visible weight and maybe I should more clearly
state the current commit policy for 5_3 on some static webpage/wiki.
But I also think this is not the right moment to come up with such
policies. After we get 5.3.0 stable out expect an RFC that will
hopefully outline how to improve things so that the release process is
able to produce higher quality code with less hassle for contributors.
Back to the patch at hand. Like I said, the patch looks safe, however
the devil is in the detail as with many seemlingly simply things. As
Johannes has pointed out already, there is the question of what
happens if TMPDIR=.
So please do revert this patch.
regards,
Lukas
On 24-Jun-09, at 9:14 AM, Johannes Schlüter wrote:
Hi Ilia,
On Wed, 2009-06-24 at 12:21 +, Ilia Alshanetsky wrote:
MFB: Fixed bug #48465 (sys_get_temp_dir() possibly inconsistent
when using
TMPDIR).
First: I'd like to remind about what Lukas wrote as we planned to
release 5.3.0 with as little source for trouble as possible:
If issues are found/fixed please send the patches to
internals for review.
Others didn't do that either but at least asked for review on IRC or
private mail ...
Would be nice if all could follow a stricter review process till
5.3 is
tagged (see the mail Lukas will send in a few minutes to internals,
too)
Seondly:
@@ -200,7 +200,14 @@
{
char* s = getenv(TMPDIR);
if (s) {
- temporary_directory = strdup(s);
+ int len = strlen(s);
+
+ if (s[len - 1] == DEFAULT_SLASH) {
+ temporary_directory = zend_strndup(s, len - 1);
This seems to be broken in case TMPDIR=.
johannes
+ } else {
+ temporary_directory = zend_strndup(s, len);
+ }
+
return temporary_directory;
}
}
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] PHP 5.3.0RC4
On 19.06.2009, at 10:50, Lukas Kahwe Smith wrote: Hello! we have packaged PHP 5.3.0RC4, which you can find here: http://downloads.php.net/johannes/ Windows binaries are available here: http://windows.php.net/qa/ This this release candidate focused on bug fixes and stability improvements and we hope to only require minimal changes ahead of the next release. Many, but not all, of the new features are already integrated in the official documentation on php.net. We aim to release PHP 5.3.0 next week. In case of critical issues we will continue producing weekly RCs. For most users there will not be a noticeable change meaning that now is the time to really do the final testing of PHP 5.3.0 before it gets released with any unnecessary incompatibilities with your project. We are really close, however there is obviously a steady stream of new tickets being opened [1]. Some of these include bugs in new functionality and some include BC breaks. At this point Johannes and I are not aware of any show stopper bugs yet though. We very much appreciate every effort to review those bug reports and as much testing as possible with real world applications. Please let us know ASAP if you do think that there is a show stopper bug. Also please do not commit to 5_3 without the explicit permission of Johannes. Please post any 5_3 patches to internals for peer review. We have had a few last minute commits break things and so we ask you to accept this additional step before commits for the hopefully short time period until 5.3.0 stable. Best Regards, Lukas and Johannes PHP 5.3 Release Managers [1] http://bugs.php.net/search.php?status=Openphpver=5.3cmd=display -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Last steps towards 5.3.0
On 10.06.2009, at 16:43, Johannes Schlüter wrote: June 10th (today): We package RC3, until then only critical build fixes and similar which have to go in the RC, after review (highlight me on IRC, mail etc.) June 11th: RC3 will be released June 11th-17th A small window for critical fixes and again please check beforehand as we don't want to introduce any new bugs that late in the game. June 17th In case there were commits after RC3 we will package a RC 4 on Wednesday next week Ok, we are here now. So we are in a commit freeze as of this morning until sometime Wednesday. When we have tagged RC4, please only commit to 5_3 with the explicit blessing of Johannes until we release 5_3 stable or announce an extension of the RC phase. So far I want to get clarification on how set_magic_quotes_runtime(0) behaves in PHP6. I also talked to Pierre about the late changes in windows (which Johannes and I were aware of since weeks). Its clear that this change will not hold up any releases. Pierre will revert if necessary. June 18th If needed publish RC4 June 18th - June 24th The plan is to repackage RC4 as 5.3.0 final in the beginning of the week of the 21st without any further changes so we can test the packages. In case something critical, unexpected, pops up please notify us asap. June 25th 2009 Release PHP 5.3.0 final. We are still on track for this one. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/curl interface.c
On 10.06.2009, at 13:10, Antony Dovgal wrote: tony2001Wed Jun 10 11:10:01 2009 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/curlinterface.c Log: MFH: fix arginfo for curl_multi_info_read() Please revert. We are in a commit freeze for the 5_3 branch as announced last week and this week again. Thx. As always, if you want someone to remind you of a merge because of a commit freeze, just let me know and I will remind you once the freeze is over. Its really not about how obvious the bug fix is. We all know that we all also make obvious mistakes at time and its just really ver inconvenient if we have such stuff during the final build testing right before an RC. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/curl interface.c
On 10.06.2009, at 14:25, Jani Taskinen wrote: If you're so anal about this, you better keep very good track on what does NOT get merged to what branch because of this freeze of yours. Yes I will. Also it doesnt have anything to do with anal .. it simply doesnt work to get reliable build testing and fixing done if we constantly have commits for bug fixes going on. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] commit freeze for 5.3 branch ahead of thursdays RC3 release
Ahoi, Just a heads up, as announced last week, we are in a commit freeze effective since this morning on the 5.3 branch. If all goes according to plan we will release RC3 this Thursday hoping for this release to become the golden stable release. We will announce the end of the commit freeze sometime during Wednesday. As things look we will stick with re2c as is (including Dmitry's hack to fallback to 5.2 behavior if the new mmap solution doesnt work). Derick is close to having a full fix, but Derick is short on time to really get out all the kinks this can also just get into 5.3.1. Again a commit freeze means no commits to any part unless its clearly a build fix or just touches README's. When in doubt ask Johannes (who should be available again some time tonight). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/mysqlnd mysqlnd_palloc.c mysqlnd_wireprotocol.c
On 08.06.2009, at 12:20, Andrey Hristov wrote: andrey Mon Jun 8 10:20:27 2009 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/mysqlnd mysqlnd_palloc.c mysqlnd_wireprotocol.c Log: Merge with HEAD. Someone committed changes to HEAD and did not merge back to the branch. Also switch off the zval cache, for now. puh .. you are aware that we want to do a commit freeze tonight? and release RC3, which should hopefully become the stable release for 5.3? since 2-3 weeks there is a constant stream of patches that seem to do pretty fundamental changes and design choices. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / README.PARAMETER_PARSING_API /win32/build config.w32 ZendEngine2 Zend.m4 zend_API.c zend_compile.c zend_execute.c zend_execute_API.c zend_operators.c zend_operators.h ze
On 08.06.2009, at 09:26, Antony Dovgal wrote: On 05.06.2009 21:15, Matt Wilmas wrote: ext/standard/tests/strings/chunk_split_variation2.phpt ext/standard/tests/strings/chunk_split_variation5.phpt ext/standard/tests/strings/chunk_split_variation8.phpt It looks like these should also be failing with 5.2 on 64-bit? Well, they don't. I'll leave them as-is for now then... Some options: Skip them on 64-bit? variation2 could have a 64-bit version added. variation5/8 look like the same thing (and don't get why they reference Bug #42796). Their logic for the test value (PHP_INT_MAX * 3) is flawed anyway with the old (err, formerly new) double-long conversion method, but that could be changed to get the same result cross-platform... Sounds like we have a BC issue? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] commit freeze for non build fixes until 5.3.0RC2 release (was: Re: [PHP-DEV] PHP 5.3.0RC2)
On 28.04.2009, at 12:51, Lukas Kahwe Smith wrote: Aloha, So seriously .. Thursday next week we will release RC2. This means a commit freeze for all but build fixes and README commits starting Monday evening. Also with RC2 any feature additions, regardless of how small, will no longer be allowed (when in doubt if a patch is a feature addition or a bug fix, ask one of the RMs). We are looking to really wrap things up quickly now. So if necessary expect an RC3 within 2 weeks after RC2. And we will continue with this cycle until we have a final release. Just as a reminder, we are now in a commit freeze until we have tagged RC2. If all goes well we will have the tag done sometime tomorrow. Please until then only do commits that are very well tested and that address build fixes. Commits to README's etc are also still legit. When in doubt talk to Johannes and Pierre pr proxy your requests through me (though I am not the one to make technical decisions). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] cvs commit freeze for the 5.3 branch
Hello, We are not in a commit freeze on the 5_3 branch. For today for any commit not just affecting README's (as in anything affecting buolding or build testing), please get a nod from Johannes or myself. On the weekend and Monday only build related fixes are allowed in the 5_3 branch. Please keep track of any HEAD commits that need merging or let me know about them so I can keep track of them (dunno if it makes sense to just write a note in the HEAD commit that this changes needs merging into 5_3). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] Re: [PHP-DEV] cvs commit freeze for the 5.3 branch
On 20.03.2009, at 12:37, Ferenc Kovacs wrote: On Fri, Mar 20, 2009 at 12:01 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: Hello, We are not in a commit freeze on the 5_3 branch. For today for any commit not just affecting README's (as in anything affecting buolding or build testing), please get a nod from Johannes or myself. On the weekend and Monday only build related fixes are allowed in the 5_3 branch. Please keep track of any HEAD commits that need merging or let me know about them so I can keep track of them (dunno if it makes sense to just write a note in the HEAD commit that this changes needs merging into 5_3). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php you mean We are noW in a commit freeze on the 5_3 branch. Right .. we are NOW in a commit freeze period. We will let everybody know on Monday or Tuesday when commits are allowed again. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / NEWS
On 22.11.2008, at 15:35, David Coallier wrote: davidc Sat Nov 22 14:35:40 2008 UTC Modified files: /php-src NEWS Log: - Added the fixed bug #46615 http://cvs.php.net/viewvc.cgi/php-src/NEWS?r1=1.2171r2=1.2172diff_format=u Index: php-src/NEWS diff -u php-src/NEWS:1.2171 php-src/NEWS:1.2172 --- php-src/NEWS:1.2171 Mon Nov 10 14:46:50 2008 +++ php-src/NEWSSat Nov 22 14:35:39 2008 @@ -51,3 +51,5 @@ - Added shm_has_var() function. (Mike) - Fixed bug #40325 (Vary: header missing in gzip output handlers). (Mike) +- Fixed bug #46615 (Make SplHeap-key() returns the key count -1 instead + of the key count). (David C.) only one NEWS file entry per change .. as in the earliest branch that will get released with the change. i have recently updated the README on this point: http://php.net/reST/php-src/README.CVS-RULES regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/sybase_ct php_sybase_ct.c
On 09.11.2008, at 12:51, Antony Dovgal wrote: On 09.11.2008 14:47, Timm Friebe wrote: Hi, Kalle, [snip] Shouldn't all these changes to sybase_ct not be in HEAD too? Yes, but I'm focusing on PHP_5_2 and PHP_5_3 for bugfixes and tests at the moment because both are near to a release:) That's simply wrong. You should be working on HEAD and merging the fixes to other branches (if needed). Hey Timm, I know there are a lot of rules to digest. Some of them are written down however: http://www.php.net/reST/php-src/README.CVS-RULES Some or missing or are not quite clear. I just committed an update to the above document (should show up in an hour or two on that site) that clarifies some of the issues you have run into. Latest version is of course always available in HEAD CVS. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / README.CVS-RULES
On 09.11.2008, at 16:16, Jani Taskinen wrote: Why not MFH to the stable branch too? a.k.a. PHP_5_2.. in the past i have been told to not MFH these kinds of README changes to maintenance branches. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / README.RELEASE_PROCESS
On 04.09.2008, at 16:26, Lukas Kahwe Smith wrote: Summary: - So lesson learned from my side (and thanks to the readme for future RMs as well). - Pierre will handle creation of a libming 0.3 compatible ext/ming PECL release - ext/fbsql history can probably be saved - ext/fdf and ext/sybase are dead and should probably not be in pecl - ext/ncurses has been moved a while ago and all is well - ext/dbase history is not going to be available via cvs.php.net/ pecl unless someone is willing to put in the time just so that i really learned my lesson i now hopefully restored fbsql, ming, dbase and sybase in PECL. Derick copied the current state from php-src over what we had in PECL and i then restore the state in HEAD and the 5_3 branch in PECL. hope this works for all .. ext/fdf is not moved to PECL at all and ext/ncurses, while moved improperly, was moved ages ago and has seen commits in PECL regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / README.RELEASE_PROCESS
On 31.08.2008, at 19:24, Derick Rethans wrote: If you know this so well, why did you ignore it for all the extensions that you moved to PECL? From the NEWS file: - Moved extensions to PECL (Pierre): . ext/dbase . ext/fbsql . ext/ming . ext/sybase (not maintained anymore, sybase_ct has to be used instead) Those four all have no history anymore in pecl/extname Yes, its far from trivial to restore the history now in order to move it to PECL. However the history is obviously not lost, its still available in php-src. Of course it would be ideal if it would be available in PECL too, but I personally do not think its worth the trouble to attempt to restore things so that the history can be moved to PECL. For the future I have noted down the steps in the release process readme. For ext/ming Pierre has promised to do the 0.3 compatible release based on PHP 5.2. Frank will handle things from then on. Note that ext/ ming is not developed in php-src, so there is probably little we really care about in the history in terms of on going development in pecl, since after all it will not be developed in pecl. Actually it might make sense to not even have it in pecl cvs at all. I saw that ext/fbsql still exists in HEAD. I am not sure if this means its still possible to move the history. If yes then let me know (or better yet let [EMAIL PROTECTED] know) so it can be moved properly. For ext/sybase I am not even sure if we want to have it in pecl at all. The extension is available from the php-src attic and we do not really expect (or want) development to continue since the ext is quite dead (both in terms of code and by the fact that sybase_ct has superseded the extension). This leaves ext/dbase as the only one where it is in fact a pitty we have lost history. If someone knows a magic way to resurrect the history let me know. . ext/ncurses Wasn't even moved now, but three years ago by hartmut. Right, which means its not relevant to the question of having to restore from the attic. I think the way it was handled in the NEWS file mades sense. Obviously it was removed in HEAD a while ago, but the first time it will dissapear from a PHP release will be 5.3.0. . ext/fdf Doesn't even exist in pecl/. This is a commercial extension, no feedback from the original developers, so I think its reasonable not to put it into pecl. Summary: - So lesson learned from my side (and thanks to the readme for future RMs as well). - Pierre will handle creation of a libming 0.3 compatible ext/ming PECL release - ext/fbsql history can probably be saved - ext/fdf and ext/sybase are dead and should probably not be in pecl - ext/ncurses has been moved a while ago and all is well - ext/dbase history is not going to be available via cvs.php.net/pecl unless someone is willing to put in the time regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / README.RELEASE_PROCESS
On 31.08.2008, at 11:47, Hannes Magnusson wrote: On Sun, Aug 31, 2008 at 10:32, Lukas Smith [EMAIL PROTECTED] wrote: lsmith Sun Aug 31 08:32:32 2008 UTC Modified files: (Branch: PHP_5_3) /php-srcREADME.RELEASE_PROCESS Log: MFH http://cvs.php.net/viewvc.cgi/php-src/README.RELEASE_PROCESS?r1=1.1.2.8r2=1.1.2.9diff_format=u Index: php-src/README.RELEASE_PROCESS diff -u php-src/README.RELEASE_PROCESS:1.1.2.8 php-src/ README.RELEASE_PROCESS:1.1.2.9 --- php-src/README.RELEASE_PROCESS:1.1.2.8 Wed Aug 6 21:49:47 2008 +++ php-src/README.RELEASE_PROCESS Sun Aug 31 08:32:32 2008 @@ -20,6 +20,9 @@ 5. Verify the tags to be extra sure everything was tagged properly. +6. Moving extensions from/to PECL requires root level access to the CVS server. +Do not use cvs rm, because this will prevent moving the CVS history. That can't be right. The extension should be copypaste from php-src/ext/foobar to pecl/, sure, but the removal of it from php-src should be done via cvs rm cvs commit otherwise you break bunch of our scripts - especially version information listing in the manual. Sounds sensible. Anyways, I would appreciate it if someone who knows would write a howto, so that RMs can verify that things are done properly. I guess in the past Derick took care of a lot of these moves via OS level file system magic. I do not know the details on how this worked. If it was a copy or a move and if there was a cvs rm afterwards or not. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / README.RELEASE_PROCESS
On 31.08.2008, at 12:11, Pierre Joye wrote: Hi Hannes, Lukas. On Sun, Aug 31, 2008 at 12:05 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Sounds sensible. Anyways, I would appreciate it if someone who knows would write a howto, so that RMs can verify that things are done properly. I guess in the past Derick took care of a lot of these moves via OS level file system magic. I do not know the details on how this worked. If it was a copy or a move and if there was a cvs rm afterwards or not. Hannes is right, it can't be a OS Level directory move but at least a copy. Doing a move will change the previous branches and that's not desired. The ideal solution would be: - Filesystem: cp -r php-src/ext/foo pecl/ - cvs rm php-src/ext/foo If the extension is still usable or not dead (unlike sybase but like ming for example), in cooperation with the extension maintainers if any: - create the pecl.php.net/foo package and its content, license, maintainer - create the package.xml, commit - release the package (I can explain the PECL release process if necessary) sounds good to me. next question .. who can do the FS level cp? i think it would be good to have a list of people RM's can contact for this step. also this way we know the bus-faktor (after all people can disappear temporarily or permanently). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS
On 31.08.2008, at 16:56, Alexey Zakhlestin wrote: indeyetsSun Aug 31 14:56:15 2008 UTC Modified files: (Branch: PHP_5_3) /php-src NEWS Log: added entry about change in ext/session http://cvs.php.net/viewvc.cgi/php-src/NEWS?r1=1.2027.2.547.2.965.2.297r2=1.2027.2.547.2.965.2.298diff_format=u Index: php-src/NEWS diff -u php-src/NEWS:1.2027.2.547.2.965.2.297 php-src/NEWS:1.2027.2.547.2.965.2.298 --- php-src/NEWS:1.2027.2.547.2.965.2.297 Sun Aug 31 10:20:57 2008 +++ php-src/NEWSSun Aug 31 14:56:14 2008 @@ -1,6 +1,8 @@ PHP NEWS | | | | | | | | | || ?? ??? 200?, PHP 5.3.0 Alpha 2 +- Removed special treatment of /tmp path for sessions in open_basedir + context. (Alexey) - Changed bundled libmagic to use PHP memory allocation routines. (Ilia) - Changed bundled libmagic to use pcre instead of ereg. (Derick, Scott, Mikko) - Updated mime_content_type to use fileinfo. (Derick) might make sense to mention that it was introduced in 5.2.2 (or whatever version you recently mentioned). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] Re: cvs: php-src /ext/pcntl EXPERIMENTAL
On 07.08.2008, at 16:59, Arnaud Le Blanc wrote: Hi, On Thursday 07 August 2008 16:48:30 Johannes Schlüter wrote: Hi, On Thu, 2008-08-07 at 13:07 +, Antony Dovgal wrote: tony2001Thu Aug 7 13:07:07 2008 UTC Removed files: /php-src/ext/pcntl EXPERIMENTAL Log: remove EXPERIMENTAL flag The EXTENSIONS file says EXTENSION: pcntl MAINTENANCE: Unknown STATUS: Working Now that we're removing the EXPERIMENTAL flag: Anybody who wants to step in? johannes If you mean that a maintainer is needed for pcntl, I'm interested in maintaining it :) I was just going to propose you :) regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/spl spl_iterators.c
Hi,
was this issue dealt with?
regards,
Lukas
On 30.07.2008, at 02:46, Marcus Boerger wrote:
Hello Dmitry,
please revert. An array has no natural string representation. So we
do
want the message here as much as we see it in comparable
situations. This
is a design decision, I actually played with yout version and did not
like it really.
marcus
Tuesday, July 29, 2008, 1:50:05 PM, you wrote:
dmitry Tue Jul 29 11:50:05 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src/ext/splspl_iterators.c
Log:
Removed warning
http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_iterators.c?r1=1.73.2.30.2.28.2.10r2=1.73.2.30.2.28.2.11diff_format=u
Index: php-src/ext/spl/spl_iterators.c
diff -u php-src/ext/spl/spl_iterators.c:1.73.2.30.2.28.2.10
php-src/ext/spl/spl_iterators.c:1.73.2.30.2.28.2.11
--- php-src/ext/spl/spl_iterators.c:1.73.2.30.2.28.2.10 Sat
Jul 19 19:45:55 2008
+++ php-src/ext/spl/spl_iterators.c Tue Jul 29 11:50:05 2008
@@ -16,7 +16,7 @@
+
--+
*/
-/* $Id: spl_iterators.c,v 1.73.2.30.2.28.2.10 2008/07/19 19:45:55
colder Exp $ */
+/* $Id: spl_iterators.c,v 1.73.2.30.2.28.2.11 2008/07/29 11:50:05
dmitry Exp $ */
#ifdef HAVE_CONFIG_H
# include config.h
@@ -924,7 +924,12 @@
php_set_error_handling(EH_THROW,
spl_ce_UnexpectedValueException TSRMLS_CC);
RETVAL_ZVAL(*data, 1, 0);
- convert_to_string(return_value);
+ if (Z_TYPE_P(return_value) == IS_ARRAY) {
+ zval_dtor(return_value);
+ ZVAL_STRINGL(return_value, Array,
sizeof(Array)-1, 1);
+ } else {
+ convert_to_string(return_value);
+ }
php_set_error_handling(EH_NORMAL, NULL TSRMLS_CC);
}
Best regards,
Marcus
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src / README.RELEASE_PROCESS
On 06.08.2008, at 21:37, Stanislav Malyshev wrote: Hi! +General notes and tipps I think you have a typpo here ;) Bah, why does english have to be different than german? :) regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard string.c
On 31.07.2008, at 09:18, Derick Rethans wrote: On Mon, 28 Jul 2008, Olivier Hill wrote: Indeed, I forgot to test that case. If I remember correctly, there was no test cases for that function, so I'll fix this tonight and add some tests. I didn't see a commit - have you forgotten about it? regards, Derick still not MFH'ed .. or? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/mysql config.m4 php_mysql.c php_mysql_structs.h /ext/mysqli mysqli.c php_mysqli_structs.h /ext/pdo_mysql config.m4 mysql_driver.c pdo_mysql.c php_pdo_mysql_int.h
On 21.07.2008, at 15:19, Jani Taskinen wrote: I don't know who invented MFB.. I guess it's its a last resort attempt to save a bunny when you screwed up with a commit .. therefore it should be called SAB (saving a bunny). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c
On 01.02.2008, at 23:05, Pierre Joye wrote: 2008/2/1 Marcus Boerger [EMAIL PROTECTED]: Crosspost, hopefully silencing this issue for 5.* AND 6 will have an E_WARNING or even an E_ERROR on this. What are the gains? What are the real reasons behing strictness? I really get annoying by adding fatal errors all around for no technical reasons. A fatal error means the engine is getting foo bared and can't do anything sane but leaving. Yes .. I think for PHP we should follow these rules: 1) No fatal errors that are not fatal for the engine 2) throw E_STRICT for anything that makes a CS prof commit suicide PHP is about solving real world problems and not creating problems that are not there (making on fatal things fatal is creating a non existant problem). if people want to do the right thing in terms of CS they enable E_STRICT .. and if they want E_STRICT to be fatal they can create an error handler that does that for them. regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/soap php_encoding.c /ext/soap/tests server030.phpt server030.wsdl
On Dec 27, 2007, at 2:44 PM, Hannes Magnusson wrote: On Dec 27, 2007 2:10 PM, Dmitry Stogov [EMAIL PROTECTED] wrote: dmitry Thu Dec 27 13:10:20 2007 UTC Added files: (Branch: PHP_5_3) /php-src/ext/soap/tests server030.phpt server030.wsdl Modified files: /php-srcNEWS /php-src/ext/soap php_encoding.c Log: Added ability to use SplArrays instead of plain arrays in ext/ soap. (Joshua Reese, Dmitry) You don't think this is going to be confusing for the users in the end? Slowly adding support for ArrayObject and ArrayIterator (but not ArrayAccess) to random extensions... Then within few releases you can use ArrayObject/Iterators here, here and here - but not there... Should we maybe start a list of functions/extensions where you can use SPL Arrays? -Hannes ps _please_ use the [DOC] tag if you want new features to be documented by the phpdoc team. I guess in this context we should also decide to make SPL a required extension in PHP. regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] Re: cvs: php-src /ext/pdo pdo_sql_parser.c pdo_sql_parser.re /ext/pdo/tests bug_43130.phpt
On 16.11.2007, at 14:21, Ilia Alshanetsky wrote: I don't see why PDO should follow oracle's rules for generic functionality. I think current implementation is good as is. 1) its a BC break that can affect any user 2) this can break queries for Oracle users porting to PDO in a very non obvious way 3) the benefit of change are close to zero Given that PDO wants to be this thin layer that unifies the client API and only wants to provide some basic emulation, you are diverging quite far from this mantra for a simple convinience feature that does considerable harm. regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: cvs: php-src / README.CVS-RULES
On 22.11.2007, at 23:11, Johannes Schlüter wrote: Lukas, once again: Thanks for your work! A small comment below: On Thu, 2007-11-22 at 18:12 +, Lukas Smith wrote: + PHP_5_2 Is used to release the PHP 5.2.x series. Only minor feature + enhancements may go in here, but please keep that as infrequent as + possible. + Shouldn't that say Only bug fixes instead of feature enhancements? Well, I was not sure about that one. I left that text unmodified. regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] Re: cvs: php-src /ext/pdo pdo_sql_parser.c pdo_sql_parser.re /ext/pdo/tests bug_43130.phpt
On 01.11.2007, at 00:56, Lorenzo Alberton wrote:
Lukas Kahwe Smith wrote:
I talked to Christopher Jones (of Oracle fame) and Lorenzo (MDB2
maintainer). Its clear that the only named parameter supporting
database I know does not support dash inside named parameters. Its
also dangerous since it means that whitespace typos could have
serious hard to spot issues. I think a safe regexp for bound
parameters would look something like: /^[a-z0-9][a-z0-9_]{0,30}$/
Since I couldn't find any official reference in
the oracle documentation, I did further tests.
I can reproduce the following behaviour on two
different machines (intel P4 and Core2Duo):
- if the named parameter is all digits,
it must be 65536 or I get an ORA-01745 error.
- if the name starts with a digit,
only digits are allowed (ORA-01036)
- the hyphen (-) is forbidden (ORA-01036)
- the name can't start with an underscore (ORA-01036),
but can contain it elsewhere
- the (alpha-numeric) name must be = 30 chars(ORA-00972)
- trivia: some non-standard ASCII chars (àòùéèç#$!)
are considered valid, but not all of them (°§£)
so please someone revert this change ... or better yet implement the
above rules.
regards,
Lukas
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] Re: cvs: php-src /ext/pdo pdo_sql_parser.c pdo_sql_parser.re /ext/pdo/tests bug_43130.phpt
On 30.10.2007, at 12:00, Johannes Schlüter wrote:
Ilia,
I don't think this is right. SQL operators shouldn't be part of a
parameter name imo.
I talked to Christopher Jones (of Oracle fame) and Lorenzo (MDB2
maintainer). Its clear that the only named parameter supporting
database I know does not support dash inside named parameters. Its
also dangerous since it means that whitespace typos could have
serious hard to spot issues.
I think a safe regexp for bound parameters would look something like:
/^[a-z0-9][a-z0-9_]{0,30}$/
regards,
Lukas
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/bcmath bcmath.c /ext/bz2 bz2.c /ext/calendar calendar.c /ext/com_dotnet com_extension.c com_persist.c /ext/ctype ctype.c /ext/curl interface.c
Johannes Schlüter wrote: Dmitry Stogov wrote: Yes, of course. I'll update it soon. I am going to backport several other patches nearest days, so I'm not sure if I should update version every day. It should be enough to change it once before an release. People running snapshots should expect stuff to break during development :-) Maybe another point to add to the release checklist? regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/pdo_mysql mysql_statement.c
Ilia Alshanetsky wrote: iliaa Sun Apr 15 16:50:42 2007 UTC Modified files: (Branch: PHP_5_2) /php-src NEWS /php-src/ext/pdo_mysql mysql_statement.c Log: Fixed bug #40935 (pdo_mysql does not raise an exception on empty fetchAll()). Why should there be an exception for a fetchAll() call in an empty result? Or am I misunderstanding the commit message? regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_1) /sapi/cgi cgi_main.c
Dmitry Stogov wrote: dmitry Fri Apr 7 13:45:23 2006 UTC Modified files: (Branch: PHP_5_1) /php-src/sapi/cgi cgi_main.c Log: CGI anf FastCGI assume $_SERVER and $_ENV have the same values, so we don't need construct the same arrays twich and may just copy it Are you sure that this is a safe enough assumption that it should be made in RC2 of 5.1.3? regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_1) /ext/xmlreader php_xmlreader.c
Marcus Boerger wrote: helly Thu Mar 30 17:37:50 2006 UTC Modified files: (Branch: PHP_5_1) /php-src/ext/xmlreader php_xmlreader.c Log: - MFH Return NULL instead of '' if node does not exist dont you think this could cause issues for people .. maybe wait for 5.2? regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_1) /ext/pgsql pgsql.c
Yasuo Ohgaki wrote: yohgaki Mon Mar 27 02:59:55 2006 UTC Modified files: (Branch: PHP_5_1) /php-src/ext/pgsql pgsql.c Log: remove pg_execute() E_WARNING error when query plan is not defined Sorry but I do not understand the logic behind this change. Nor do I think this should go into 5.1.3. I think it makes perfect sense to get and E_WARNING for this. Of course there are other ways to check if an error did ocurr. Maybe I am misunderstanding the scope of the change, but from your comments on internals it just seems you need to beef up your customer error handler to ignore supressed errors. regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src(PHP_5_0) /ext/standard php_incomplete_class.h
hi, furthermore are you aware that there are several fixes that are also not applied to 5.0.x (atleast I know for sure that several streams fixes fall into this category). I really dont see the point in doing more 5.0.x releases if they dont fix countless bugs that are marked as fixed in CVS. Maybe Wez's milestone feature could bring some clarity to users but spending another second on 5.0.x seems like a waste of ressources that should be directed at 5.1.0. regards, Lukas -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
