[PHP-DEV] RC announcements at php.net
Hello all. Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable. Any objections? I hope none. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
I think it makes sense for RC1 and few of the first level releases but not the very closely spaces RC4+ where there are virtually no changes between the releases. On 15-Feb-07, at 9:38 AM, Antony Dovgal wrote: Hello all. Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable. Any objections? I hope none. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote: I think it makes sense for RC1 and few of the first level releases but not the very closely spaces RC4+ where there are virtually no changes between the releases. I believe it doesn't matter which RC is that, it helps to detect problems on the early stage anyway. I wouldn't like to miss a bug just because someone missed an RC announcement. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
Antony Dovgal wrote: On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote: I think it makes sense for RC1 and few of the first level releases but not the very closely spaces RC4+ where there are virtually no changes between the releases. I believe it doesn't matter which RC is that, it helps to detect problems on the early stage anyway. I wouldn't like to miss a bug just because someone missed an RC announcement. Also it will be too untransparent for users what RC's get published and which dont .. Whatever the decision please add it to the release check list on the wiki :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
On 2/15/07, Antony Dovgal [EMAIL PROTECTED] wrote: On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote: I think it makes sense for RC1 and few of the first level releases but not the very closely spaces RC4+ where there are virtually no changes between the releases. I believe it doesn't matter which RC is that, it helps to detect problems on the early stage anyway. I wouldn't like to miss a bug just because someone missed an RC announcement. I agree. All releases should be announced. I can imagine a little image to tell when a release announcement is QA (RC) release or the final release. I'm not sure it will help to get more testers or feedbacks, but it costs nothing to do it :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
probably, here should be a block on the main page: Latest testing release: X.X.XRC1 (changelog) Latest stable release: X.X.X (changelog) and testing release should just disappear when there are no release candidates available -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
On 02/15/2007 06:49 PM, Alexey Zakhlestin wrote: probably, here should be a block on the main page: Latest testing release: X.X.XRC1 (changelog) Latest stable release: X.X.X (changelog) and testing release should just disappear when there are no release candidates available Yeah, I would mind if we merge this part of qa.php.net into php.net. It's just a small block, but it would help us to gain a lot of feedback. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
Hi Tony, We've been here before. Last time it got taken off again because it led to user confusion. People didn't seem to know the difference between a release candidate and a full release; It was official, it was on php.net. Please can it be made VERY clear, both in the announcements and on the download page (qa.php.net?) that RC's are for test purposes only? Cheers, - Steph - Original Message - From: Antony Dovgal [EMAIL PROTECTED] To: php-dev internals@lists.php.net Sent: Thursday, February 15, 2007 2:38 PM Subject: [PHP-DEV] RC announcements at php.net Hello all. Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable. Any objections? I hope none. -- Wbr, Antony Dovgal -- 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] RC announcements at php.net
On 02/15/2007 07:42 PM, Steph Fox wrote: On 02/15/2007 07:22 PM, Steph Fox wrote: Hi Tony, We've been here before. Last time it got taken off again because it led to user confusion. People didn't seem to know the difference between a release candidate and a full release; It was official, it was on php.net. .. it was explained that it's not a release, but a release candidate. ? I know that, you know that, but thousands don't know what a release candidate even is :) Then we should describe the difference as clear as we can. Please can it be made VERY clear, both in the announcements and on the download page (qa.php.net?) that RC's are for test purposes only? That depends on the wording and I hope you'll help us to find the best one, as a native speaker =) Thanks in advance =) -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: runtime JIT
Just to be clear: does this implement runtime JIT per-element or for the whole array at once? -Andrei On Feb 14, 2007, at 4:07 AM, Dmitry Stogov wrote: The patch is attached. To use runtime JIT you will need to change zend_register_auto_global() to zend_register_auto_global_ex() with 1 as the last argument. Compile-time JIT is still supported too. Note that the significant part of the patch is reverting of autoglobals CV patch, that is reimplemented using CG(auto_globals_cache). Any objections? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RC announcements at php.net
Antony Dovgal wrote: Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. Any objections? I hope none. I actually think this is a pretty good idea, and thanks to Hannes for the cleanup. -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: runtime JIT
On 2/15/07, Andrei Zmievski [EMAIL PROTECTED] wrote: Just to be clear: does this implement runtime JIT per-element or for the whole array at once? The whole array. It is exactly like what we have now for the compile-time JIT. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] imap on windows
Hi! Does anybody know how to build IMAP module successfully on WIndows? I try to build it and I get this: cclient.lib(os_w2k.obj) : error LNK2005: _flock already defined in flock_compat.obj cclient.lib(os_w2k.obj) : error LNK2005: _openlog already defined in wsyslog.obj cclient.lib(os_w2k.obj) : error LNK2005: _syslog already defined in wsyslog.obj So obviously we have symbol clash between cclient library and PHP. Does anybody know the good way to fix it? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] imap on windows
Hi Stanislav, IIRC, you need to modify the Makefile.w2k in c-client. Change the Link flag /MT to /MD, rebuild imap and rebuild php_imap.dll - Frank Hi! Does anybody know how to build IMAP module successfully on WIndows? I try to build it and I get this: cclient.lib(os_w2k.obj) : error LNK2005: _flock already defined in flock_compat.obj cclient.lib(os_w2k.obj) : error LNK2005: _openlog already defined in wsyslog.obj cclient.lib(os_w2k.obj) : error LNK2005: _syslog already defined in wsyslog.obj So obviously we have symbol clash between cclient library and PHP. Does anybody know the good way to fix it? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- 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] imap on windows
IIRC, you need to modify the Makefile.w2k in c-client. Change the Link flag /MT to /MD, rebuild imap and rebuild php_imap.dll I took cclient.lib from win32build.zip library package from php.net. So I guess this package has to be fixed? I don't know who built it though... -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
On 02/15/2007 05:38 PM, Antony Dovgal wrote: Hello all. Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable. Any objections? I hope none. Just to quote Greg here: CelloG you could solve Steph's concern by putting the testing release block in a different place CelloG put the official current release block in the upper left CelloG and the testing block down on the left a little lower This sounds like the way to go. We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net and add a link to that page in the block. Actually, I'll try to write something tomorrow. Any more volunteers to patch php.net? Hannes? You seem to be the most active person in that area atm =) -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
Hi On 2/15/07, Antony Dovgal [EMAIL PROTECTED] wrote: On 02/15/2007 05:38 PM, Antony Dovgal wrote: Hello all. Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable. Any objections? I hope none. Just to quote Greg here: CelloG you could solve Steph's concern by putting the testing release block in a different place CelloG put the official current release block in the upper left CelloG and the testing block down on the left a little lower This sounds like the way to go. We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net and add a link to that page in the block. Actually, I'll try to write something tomorrow. Any more volunteers to patch php.net? Hannes? You seem to be the most active person in that area atm =) As I am all for the idea I will definitely prepare a patch -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
I'm +1 on the separate block. SUGGESTIONS: Put the STABLE RELEASE link *before* any RC release. Rationale: Users in a hurry will more likely click the first one. Add an EXTRA page in between the homepage and download of RC saying something not unlike: You are downloading a RELEASE CANDIDATE. This should be used for TEST PURPOSES ONLY. Make the user read that and click an extra button/step. Yes, it is slightly more inconvenient, and that's a Good Thing Instead of RELEASE CANDIDATE just call it UNSTABLE or TEST branch in the text of the link. On Thu, February 15, 2007 10:42 am, Steph Fox wrote: On 02/15/2007 07:22 PM, Steph Fox wrote: Hi Tony, We've been here before. Last time it got taken off again because it led to user confusion. People didn't seem to know the difference between a release candidate and a full release; It was official, it was on php.net. .. it was explained that it's not a release, but a release candidate. ? I know that, you know that, but thousands don't know what a release candidate even is :) Please can it be made VERY clear, both in the announcements and on the download page (qa.php.net?) that RC's are for test purposes only? That depends on the wording and I hope you'll help us to find the best one, as a native speaker =) Sure. Ping me. - Steph -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion: global variables being accessed in localscope
[Taking this back on-list, as it's my final answer.] On Wed, February 14, 2007 5:30 pm, Christian Schneider wrote: Richard Lynch wrote: But the code that checks for E_NOTICE also has to be altered to check for E_STRICT... How many applications use error handlers. And how many of them rely on a specific code being a specific level? Out of curiousity: I wouldn't even know why someone would do something like that, perhaps you have a good example. Anyway, that's a BC break I find worth doing but I'm fully aware that you will disagree. Anybody on shared hosting who wants to log their errors somewhere out of the morass of system logs without dinking around with .htaccess is going to use set_error_handler. For that matter, if .htaccess is off, and you can't edit php.ini, set_error_handler is just about your only option for reasonable error handling. I think you will find that a LOT of distributed applications use this to avoid splatting PHP error messages out. Or, at least, they should be using it, as there's no other way without using something you can't rely on if your code is widely distributed in unknown environments. I know *I* have used it more than a few times. Once you decide to use set_error_handler, of course you are going to treat E_ERROR, E_NOTICE, E_USER_ERROR differently. You want to just halt your script for E_ERROR, but probably just tell yourself to fix the buglet of an E_NOTICE. You may even put them in separate logs, or perhaps even email yourself E_ERROR, but only log E_NOTICE. I *know* I have switch() statements on the error level in my error handlers, and you are going to break them. I can understand why the purist / anal-retentive camp wants un-initiliazed varaibles as E_STRICT rather than E_NOTICE, but does it really make that much difference? And, honestly, there *ARE* bugs that can be introduced if somebody makes a typo that results in using an unitialized variable. Though the PHP auto-initialization to '' (or 0 or false or whatever is suitable after type-juggling) works 99% of the time, imagine something like this: ?php /* lots of code */ $foo = 42; /* lots of code */ if ($foo === 42) echo foo!; ? Now imagine that somebody deletes all the lots of code and also accidentally deletes the initialization. The thing you believe should be E_STRICT is, in fact, an E_NOTICE worthy issue. Not only CAN this happen, it HAS happened to me, and the E_NOTICE made it patently obvious what had happened as soon as I ran my tests. Therefore, I believe the uninitialized variables should NOT be moved to E_STRICT. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
