Re: [PHP-DEV] RFC: ext/mysql deprecation
hi Anthony, On Mon, Nov 19, 2012 at 6:22 PM, Anthony Ferrara ircmax...@gmail.com wrote: Kris, By NEXT are you referring to 6.0 or 5.6? Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the next temporal release... Also, can you add an option for raising E_DEPRECATED in 5.5 then removing support altogether in 6? That's already in there. That's what I mean by hard-deprecating it for 5.5... And in either case, removal would happen one release after hard deprecation... I do not follow the logic. It is too heavy to use the right deprecation flag for the connect function only, but it is perfectly fine to kill one of the most widely used extension in php history in a minor version? I'd rather go with the flag and kill it in 6. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 16.11.2012 03:23, schrieb Sherif Ramadan: People have been talking about and educating others about the deprecation of ext/mysql for quite some time now. I'm sure that it Random dates in the lifes of ext/mysql[i]: 2003 * ext/mysqli, the improved version of ext/mysql gets developed * Int. PHP Conference ext/mysqli talk * Similar talk given at the local PHP meetup in Hamburg includes Migration from mysql to mysqli * Zak Greant and Georg Richter publish Zend.com article 2004 * PHP 5.0.0 ships ext/mysqli * 2x Int. PHP Conference PHP5 + MySQL 4.1/5.0 (= requires ext/mysqli, mysqli was made for 4.1/5.0) * ApacheCon Europe PHP5 + MySQL 2006 * MySQL recommends mysqli and publishes a conversion script http://lists.mysql.com/announce/400 * ext/mysql feature request gets won't fix https://bugs.php.net/bug.php?id=37867 * MySQL announces the plan to develop the mysqlnd library 2007 * First public mysqlnd version supports mysqli only http://lists.mysql.com/announce/432 ... 2011 * Public ext/mysql deprecation outcry 2012 * Soft-deprecation warnings added to php.net manual https://bugs.php.net/bug.php?id=62213 No judgement intended. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: ext/mysql deprecation
I just want to place a notice. Please visit http://de1.php.net/manual/de/function.mysql-query.php The suggested alternatives are still not shown in all translated versions of the docs. I am sure that there are people who look in the docs but have never seen the suggestions before (like me)... I was forced to use PDO because of several frameworks and learned the advantages ;-) Best regards Christian -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Tuesday, November 20, 2012 9:29 AM To: Anthony Ferrara Cc: Kris Craig; Adam Harvey; Chad Emrys; Patrick Allaert; internals@lists.php.net Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation hi Anthony, On Mon, Nov 19, 2012 at 6:22 PM, Anthony Ferrara ircmax...@gmail.com wrote: Kris, By NEXT are you referring to 6.0 or 5.6? Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the next temporal release... Also, can you add an option for raising E_DEPRECATED in 5.5 then removing support altogether in 6? That's already in there. That's what I mean by hard-deprecating it for 5.5... And in either case, removal would happen one release after hard deprecation... I do not follow the logic. It is too heavy to use the right deprecation flag for the connect function only, but it is perfectly fine to kill one of the most widely used extension in php history in a minor version? I'd rather go with the flag and kill it in 6. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 13.11.2012 04:08, schrieb Adam Harvey: On 13 November 2012 08:44, Christopher Jones christopher.jo...@oracle.com wrote: Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This IS all about education carrots rather than irritating sticks. Perhaps there needs to be a concerted campaign to get the key tutorials such as at http://www.w3schools.com updated to a much more modern format? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 20.11.2012 11:22, schrieb Lester Caine: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This is no argument for adding this specific old wiki stuff to the RFC, is it? However, I reckon your proposal. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
https://www.google.de/search?q=php+mysqli+tutoriralaq=foq=php+mysqli+tutoriralaqs=chrome.0.57j0l2j64.6593sugexp=chrome,mod=15sourceid=chromeie=UTF-8 On Tue, Nov 20, 2012 at 11:22 AM, Lester Caine les...@lsces.co.uk wrote: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This IS all about education carrots rather than irritating sticks. Perhaps there needs to be a concerted campaign to get the key tutorials such as at http://www.w3schools.com updated to a much more modern format? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Pierre Joye wrote: https://www.google.de/search?q=php+mysqli+tutorial Which gives About 273,000 results and the first of them are causing more confusion with PDO alternative. BUT newcomers know nothing about mysqli and will be looking for https://www.google.de/search?q=php+mysql+tutorial gives About 9,040,000 The most important think here is getting the word out and getting as I said - get the more popular tutorial sites 'converted' or at least pointing out that mysqlI is now what you have to look for. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Ulf Wendel wrote: Am 20.11.2012 11:22, schrieb Lester Caine: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This is no argument for adding this specific old wiki stuff to the RFC, is it? However, I reckon your proposal. In the absence of nothing better? Ideally someone who knows mysqli inside out needs to update these documents ... I'll stick to converting mysql users to Firebird :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
2012/11/20 Lester Caine les...@lsces.co.uk Pierre Joye wrote: https://www.google.de/search?**q=php+mysqli+tutorialhttps://www.google.de/search?q=php+mysqli+tutorial Which gives About 273,000 results and the first of them are causing more confusion with PDO alternative. BUT newcomers know nothing about mysqli and will be looking for https://www.google.de/search?**q=php+mysql+tutorialhttps://www.google.de/search?q=php+mysql+tutorial gives About 9,040,000 And https://www.google.de/search?q=standart gives you 128,000,000 results. You cannot avoid, that outdated, or wrong information remains. The bigger problem seems to be, that the google results are treated with more attention, then the official manual. Any idea against that? The most important think here is getting the word out and getting as I said - get the more popular tutorial sites 'converted' or at least pointing out that mysqlI is now what you have to look for. Who should be responsible for this task in your opinion? For example why didn't you contacted w3schools already? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] RFC: ext/mysql deprecation
Am 20.11.2012 13:25, schrieb Lester Caine: Ulf Wendel wrote: Am 20.11.2012 11:22, schrieb Lester Caine: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This is no argument for adding this specific old wiki stuff to the RFC, is it? However, I reckon your proposal. In the absence of nothing better? Lester, you may want to read the fine manual: http://www.php.net/manual/en/mysqli.quickstart.php Ideally someone who knows mysqli inside out needs to update these documents ... I'll stick to converting mysql users to Firebird :) Are you aware of what you do to the discussion and the list? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Debuggers support for generators
Hi Derick,
The attached patch must enable generators support in XDebug.
XDebug would need override zend_execute_ex (instead of zend_execute).
EG(current_execute_data) is going to be different there. You can use
EG(current_execute_data)-prev_execute_data instead.
I would appreciate, if you test the patch and tell me if XDebug still
has any PHP-5.5 related problems.
Thanks. Dmitry.
diff --git a/Zend/zend.c b/Zend/zend.c
index 9ab879a..e34634c 100644
--- a/Zend/zend.c
+++ b/Zend/zend.c
@@ -684,10 +684,12 @@ int zend_startup(zend_utility_functions
*utility_functions, char **extensions TS
/* build with dtrace support */
zend_compile_file = dtrace_compile_file;
zend_execute = dtrace_execute;
+ zend_execute_ex = execute_ex; /* FIXME: dtrace support for generators */
zend_execute_internal = dtrace_execute_internal;
#else
zend_compile_file = compile_file;
zend_execute = execute;
+ zend_execute_ex = execute_ex;
zend_execute_internal = NULL;
#endif /* HAVE_SYS_SDT_H */
zend_compile_string = compile_string;
diff --git a/Zend/zend_execute.h b/Zend/zend_execute.h
index 4594eba..2d7f9ed 100644
--- a/Zend/zend_execute.h
+++ b/Zend/zend_execute.h
@@ -51,6 +51,7 @@ typedef union _temp_variable {
BEGIN_EXTERN_C()
struct _zend_fcall_info;
ZEND_API extern void (*zend_execute)(zend_op_array *op_array TSRMLS_DC);
+ZEND_API extern void (*zend_execute_ex)(zend_execute_data *execute_data
TSRMLS_DC);
ZEND_API extern void (*zend_execute_internal)(zend_execute_data
*execute_data_ptr, struct _zend_fcall_info *fci, int return_value_used
TSRMLS_DC);
void init_executor(TSRMLS_D);
diff --git a/Zend/zend_execute_API.c b/Zend/zend_execute_API.c
index 9787966..fe2f46c 100644
--- a/Zend/zend_execute_API.c
+++ b/Zend/zend_execute_API.c
@@ -39,6 +39,7 @@
#endif
ZEND_API void (*zend_execute)(zend_op_array *op_array TSRMLS_DC);
+ZEND_API void (*zend_execute_ex)(zend_execute_data *execute_data TSRMLS_DC);
ZEND_API void (*zend_execute_internal)(zend_execute_data *execute_data_ptr,
zend_fcall_info *fci, int return_value_used TSRMLS_DC);
/* true globals */
diff --git a/Zend/zend_generators.c b/Zend/zend_generators.c
index 87f0644..2826a23 100644
--- a/Zend/zend_generators.c
+++ b/Zend/zend_generators.c
@@ -533,7 +533,7 @@ void zend_generator_resume(zend_generator *generator
TSRMLS_DC) /* {{{ */
/* Resume execution */
generator-flags |= ZEND_GENERATOR_CURRENTLY_RUNNING;
- execute_ex(generator-execute_data TSRMLS_CC);
+ zend_execute_ex(generator-execute_data TSRMLS_CC);
generator-flags = ~ZEND_GENERATOR_CURRENTLY_RUNNING;
/* Restore executor globals */
diff --git a/Zend/zend_vm_def.h b/Zend/zend_vm_def.h
index b06c09f..3d9b0d7 100644
--- a/Zend/zend_vm_def.h
+++ b/Zend/zend_vm_def.h
@@ -2048,7 +2048,7 @@ ZEND_VM_HELPER(zend_do_fcall_common_helper, ANY, ANY)
if (RETURN_VALUE_USED(opline)) {
EX_T(opline-result.var).var.ptr =
zend_generator_create_zval(EG(active_op_array) TSRMLS_CC);
}
- } else if (EXPECTED(zend_execute == execute)) {
+ } else if (EXPECTED(zend_execute == execute zend_execute_ex
== execute_ex)) {
if (EXPECTED(EG(exception) == NULL)) {
ZEND_VM_ENTER();
}
@@ -3954,7 +3954,7 @@ ZEND_VM_HANDLER(73, ZEND_INCLUDE_OR_EVAL,
CONST|TMP|VAR|CV, ANY)
zend_rebuild_symbol_table(TSRMLS_C);
}
- if (EXPECTED(zend_execute == execute)) {
+ if (EXPECTED(zend_execute == execute zend_execute_ex ==
execute_ex)) {
ZEND_VM_ENTER();
} else {
zend_execute(new_op_array TSRMLS_CC);
diff --git a/Zend/zend_vm_execute.h b/Zend/zend_vm_execute.h
index 7a2cfc8..81a6b09 100644
--- a/Zend/zend_vm_execute.h
+++ b/Zend/zend_vm_execute.h
@@ -458,7 +458,7 @@ ZEND_API void execute(zend_op_array *op_array TSRMLS_DC)
if (EG(exception)) {
return;
}
- execute_ex(zend_create_execute_data_from_op_array(op_array, 0
TSRMLS_CC) TSRMLS_CC);
+ zend_execute_ex(zend_create_execute_data_from_op_array(op_array, 0
TSRMLS_CC) TSRMLS_CC);
}
static int ZEND_FASTCALL zend_leave_helper_SPEC(ZEND_OPCODE_HANDLER_ARGS)
@@ -669,7 +669,7 @@ static int ZEND_FASTCALL
zend_do_fcall_common_helper_SPEC(ZEND_OPCODE_HANDLER_AR
if (RETURN_VALUE_USED(opline)) {
EX_T(opline-result.var).var.ptr =
zend_generator_create_zval(EG(active_op_array) TSRMLS_CC);
}
- } else if (EXPECTED(zend_execute == execute)) {
+ } else if (EXPECTED(zend_execute == execute zend_execute_ex
== execute_ex)) {
if (EXPECTED(EG(exception) ==
Re: [PHP-DEV] RFC: ext/mysql deprecation
Lester, My point is: less talk, more acts. You want better docs? Contribute. Cheers, On Tue, Nov 20, 2012 at 1:23 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: https://www.google.de/search?q=php+mysqli+tutorial Which gives About 273,000 results and the first of them are causing more confusion with PDO alternative. BUT newcomers know nothing about mysqli and will be looking for https://www.google.de/search?q=php+mysql+tutorial gives About 9,040,000 The most important think here is getting the word out and getting as I said - get the more popular tutorial sites 'converted' or at least pointing out that mysqlI is now what you have to look for. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH][PHP-LDAP] Pending patches
Hi, I have two pending patches for the module php-ldap with no reply (for 5 months). Those patches are quite useful and it would be nice to have them merged or, at least, commented : [https://bugs.php.net/bug.php?id=61853] remove use of libldap deprecated functions [https://bugs.php.net/bug.php?id=61921] add support for ber value as PHP array in functions like ldap_parse_result and ldap_set_option. It also provide needed functions (ber-php array conversion) to support further improvement like ldap_extended_operation. Both patch have no impact on existing code. Regards, Etienne. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Tue, Nov 20, 2012 at 5:12 AM, Pierre Joye pierre@gmail.com wrote: Lester, My point is: less talk, more acts. You want better docs? Contribute. Cheers, I think there's definitely room for improvement in making mysqli tutorials more common and accessible, but I don't think that should cause us to delay deprecation. I do like Lester's idea of forming a task force to aggressively replace mysql tutorials with mysqli. I'd be happy to help out with that if there's sufficient interest. --Kris
Re: [PHP-DEV] RFC: ext/mysql deprecation
hi, On Tue, Nov 20, 2012 at 6:43 PM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Nov 20, 2012 at 5:12 AM, Pierre Joye pierre@gmail.com wrote: Lester, My point is: less talk, more acts. You want better docs? Contribute. Cheers, I think there's definitely room for improvement in making mysqli tutorials more common and accessible, but I don't think that should cause us to delay deprecation. I do like Lester's idea of forming a task force to aggressively replace mysql tutorials with mysqli. I'd be happy to help out with that if there's sufficient interest. A task force? http://edit.php.net and go ahead. No offense meant but there is a time to argue endlessly (rarely but..) and there is time to actually do something. I think the latter should be done now. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Tue, Nov 20, 2012 at 9:55 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Nov 20, 2012 at 6:43 PM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Nov 20, 2012 at 5:12 AM, Pierre Joye pierre@gmail.com wrote: Lester, My point is: less talk, more acts. You want better docs? Contribute. Cheers, I think there's definitely room for improvement in making mysqli tutorials more common and accessible, but I don't think that should cause us to delay deprecation. I do like Lester's idea of forming a task force to aggressively replace mysql tutorials with mysqli. I'd be happy to help out with that if there's sufficient interest. A task force? http://edit.php.net and go ahead. No offense meant but there is a time to argue endlessly (rarely but..) and there is time to actually do something. I think the latter should be done now. I agree with you, but I was referring to reaching out to external sites/blogs/etc that still have outdated mysql tutorials appearing in search results. =) --Kris
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 20/11/12 21:22, Lester Caine wrote: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This IS all about education carrots rather than irritating sticks. Perhaps there needs to be a concerted campaign to get the key tutorials such as at http://www.w3schools.com updated to a much more modern format? There was a concerted campaign to get w3schools updated, but as far as I know, it's fallen on deaf ears. And it's not just their PHP info that's outdated. See w3fools.com Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On Tue, Nov 20, 2012 at 3:32 PM, David Muir davidkm...@gmail.com wrote: On 20/11/12 21:22, Lester Caine wrote: Ulf Wendel wrote: 1. Add this link to the RFC?: https://wikis.oracle.com/**display/mysql/Converting+to+**MySQLihttps://wikis.oracle.com/display/mysql/Converting+to+MySQLi As the author I cannot recommend materials created in 2006 and not updated since then for inclusion into a RFC. At the end of the day this is the problem all around. There needs sufficient volume of mysqli examples and tutorials to at least get some on a search for 'mysql php tutorial'. This IS all about education carrots rather than irritating sticks. Perhaps there needs to be a concerted campaign to get the key tutorials such as at http://www.w3schools.com updated to a much more modern format? There was a concerted campaign to get w3schools updated, but as far as I know, it's fallen on deaf ears. And it's not just their PHP info that's outdated. See w3fools.com Cheers, David +1 on ignoring w3schools. Those guys are idiots. I'd never seen the w3fools site before and I love it! One thing in there got me thinking: One of their suggestions to w3schools is that they should wikify their content. They obviously won't do that, but what if we launched something like that instead? The PHP manual is a great functional reference point, but it's understandably thin when it comes to tutorials. What if some of us got together and launched a new wiki (I'm thinking something separate from wiki.php.net) site dedicated to providing accurate, up-to-date tutorials on how to do _ in PHP? Unlike most other sites, we'd be in a good position to displace inaccurate sources like w3schools in the search results. Just a thought, though I'm sure it's not an original one. --Kris
[PHP-DEV] Expose zend_message_dispatcher_p
Hey: This problem come out when I was figuring a performance issue of Yaf_Loader. Yaf provides a autoloader like PSR0, when doing a classes autoloading. it used to: 1. stat the file, if file does not exists, return 2. zend_compile_file this is okey when you run yaf without opcode cache. but when you run yaf with opcode cache, the first stat syscall become a little waste. since opcode cache always hook the zend_compile_file, and compile the file from cache. so, I changed the autoload to: 1. zend_compile_file 2. if compile failed, then return. but, zend_compile_file will throw warning if the file doesn't exists via zend_message_dispatcher_p so if zend_message_dispatcher_p is ZEND_API, then I can avoid using such mess codes: https://github.com/laruence/php-yaf/blob/master/yaf_loader.c#L377 what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
What if some of us got together and launched a new wiki (I'm thinking something separate from wiki.php.net) site dedicated to providing accurate, up-to-date tutorials on how to do _ in PHP? Unlike most other sites, we'd be in a good position to displace inaccurate sources like w3schools in the search results. Just a thought, though I'm sure it's not an original one. --Kris Perhaps, but this is the ext/mysql deprecation discussion. Creating a new wiki site is outside the scope of this proposal. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 19 November 2012 20:44, Anthony Ferrara ircmax...@gmail.com wrote: My intention at this stage is to call a vote next Monday: it feels like the discussion has mostly died down now (which isn't to say I think we're at a consensus necessarily — it just feels as though the flurry of opinions have been made and argued either way), and I'm hoping that everyone can have a think about where and how they'd like to see this move forward (if at all) between now and then. Given we've only just hit alpha 1, I don't think we need to rush into a decision right now for the sake of one. I completely agree. I would suggest one thing though. When it comes up for a vote, please either make 2 questions: 1. Should ext/mysql be hard-deprecated in 5.5 2. Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT Or 4 options to deprecation: 1. Hard-deprecated in 5.5 2. Soft-deprecated in 5.5 and hard-deprecated in NEXT 3. Either 4. Neither That way both viewpoints can be voted on in one vote. And we can get an accurate count of the thoughts... I've been mulling this for a couple of days, and Anthony and I have talked about this on IRC, and I'd prefer to have two questions: 1. Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no) 2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what should the next course of action be: (a) Enhance the manual text to make the soft deprecation clearer, and generate E_DEPRECATED notices in PHP 5.6 (b) Enhance the manual text to make the soft deprecation clearer, but take no further action in terms of E_DEPRECATED for the forseeable future (c) Remove the warnings from the manual and undeprecate ext/mysql entirely The reason for this is that I'd like to make the vote about the actual RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3 or 4 option vote there could easily lead to a split decision, which will make it very difficult to take any sort of decisive action. I'd rather make a decision there, then we can look at what action would be preferred if the RFC itself fails. Just to be clear: I don't think that do nothing is a very useful option for the second question, which is why I've omitted it — it doesn't seem like anyone's particularly satisfied with the current state of affairs. Thoughts? Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 21/11/12 15:47, Adam Harvey wrote: On 19 November 2012 20:44, Anthony Ferrara ircmax...@gmail.com wrote: My intention at this stage is to call a vote next Monday: it feels like the discussion has mostly died down now (which isn't to say I think we're at a consensus necessarily — it just feels as though the flurry of opinions have been made and argued either way), and I'm hoping that everyone can have a think about where and how they'd like to see this move forward (if at all) between now and then. Given we've only just hit alpha 1, I don't think we need to rush into a decision right now for the sake of one. I completely agree. I would suggest one thing though. When it comes up for a vote, please either make 2 questions: 1. Should ext/mysql be hard-deprecated in 5.5 2. Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT Or 4 options to deprecation: 1. Hard-deprecated in 5.5 2. Soft-deprecated in 5.5 and hard-deprecated in NEXT 3. Either 4. Neither That way both viewpoints can be voted on in one vote. And we can get an accurate count of the thoughts... I've been mulling this for a couple of days, and Anthony and I have talked about this on IRC, and I'd prefer to have two questions: 1. Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no) 2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what should the next course of action be: (a) Enhance the manual text to make the soft deprecation clearer, and generate E_DEPRECATED notices in PHP 5.6 (b) Enhance the manual text to make the soft deprecation clearer, but take no further action in terms of E_DEPRECATED for the forseeable future (c) Remove the warnings from the manual and undeprecate ext/mysql entirely The reason for this is that I'd like to make the vote about the actual RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3 or 4 option vote there could easily lead to a split decision, which will make it very difficult to take any sort of decisive action. I'd rather make a decision there, then we can look at what action would be preferred if the RFC itself fails. Just to be clear: I don't think that do nothing is a very useful option for the second question, which is why I've omitted it — it doesn't seem like anyone's particularly satisfied with the current state of affairs. Thoughts? Adam Has 2(c) been even suggested? I take at that 2(b) is for those advocating Move to PECL with no E_DEPRECATED notices being thrown? Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 21 November 2012 13:03, David Muir davidkm...@gmail.com wrote: On 21/11/12 15:47, Adam Harvey wrote: 2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what should the next course of action be: (a) Enhance the manual text to make the soft deprecation clearer, and generate E_DEPRECATED notices in PHP 5.6 (b) Enhance the manual text to make the soft deprecation clearer, but take no further action in terms of E_DEPRECATED for the forseeable future (c) Remove the warnings from the manual and undeprecate ext/mysql entirely Has 2(c) been even suggested? Not that I've seen, but having a none of the above, I want none of this option seems prudent. I take at that 2(b) is for those advocating Move to PECL with no E_DEPRECATED notices being thrown? Not really. We can't really unbundle and move to PECL without deprecating first anyway, IMO. It's basically the option for no real change but clarifying the manual wording, since nobody seems satisfied with it. Or, to put it another way from where I sit: the too hard, let's make a decision after stringing people along longer option. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 21 November 2012 12:47, Adam Harvey ahar...@php.net wrote: Just to be clear: I don't think that do nothing is a very useful option for the second question, which is why I've omitted it — it doesn't seem like anyone's particularly satisfied with the current state of affairs. I still think this is useless, but have been convinced off list we should have it. So add 2(d): do absolutely nothing. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
Thanks everyone, I didn't remember thinking about this so was impulsively curious. Dug a little now, so here's what happened: Proposal to internals (July 14, 2012) with discussion July 14-18: -- Thread: http://markmail.org/thread/kewdoz3dowrr7rfv Summary:Seemed okay, discussed more how than why, and more yes than maybe approved. Conclusion: No clear decision was reached. The patch: -- Patch: https://github.com/php/php-src/pull/132 Pull: http://git.php.net/?p=php-src.git;a=commitdiff;h=c9eb641 Summary:Mostly a technical/patch related discussion there, several tweaks, then pulled. Conclusion: Merged/pulled into master on August 4, 2012. What happened: -- - The PHP logo GUIDs were removed, and replaced with data URIs in phpinfo() and friends. - BC: Removed four *_logo_* functions, and GUID usage. - E_DEPRECATED was not used beforehand, nor doc updates, they were simply removed. FWIW, also no RFC. It's understandable how a minimally used feature can be changed and removed without much worry/thought. But, they appear to be the only functions removed in 5.5, and this helps it feel even easier to not break BC for this not-so-important change. Proposal: I propose we revert this change. Future consideration might include E_DEPRECATED for these functions in 5.5, although I am not proposing that part. Seems sensible, though. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
Hi! Proposal: I propose we revert this change. Future consideration might I see no reason to revert the change and keep dragging around the GUIDs. Data URLs are much better and cleaner solution, and only reasons not to do it are purely bureaucratic, for which I don't care much. We could keep the functions, but what these functions would do? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On 21 November 2012 13:45, Stas Malyshev smalys...@sugarcrm.com wrote: Proposal: I propose we revert this change. Future consideration might I see no reason to revert the change and keep dragging around the GUIDs. Data URLs are much better and cleaner solution, and only reasons not to do it are purely bureaucratic, for which I don't care much. We could keep the functions, but what these functions would do? The issue I have with this is just that we don't seem to be making much of an effort to stick to the promises we've made around BC when it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 21/11/12 16:08, Adam Harvey wrote: On 21 November 2012 13:03, David Muir davidkm...@gmail.com wrote: On 21/11/12 15:47, Adam Harvey wrote: 2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what should the next course of action be: (a) Enhance the manual text to make the soft deprecation clearer, and generate E_DEPRECATED notices in PHP 5.6 (b) Enhance the manual text to make the soft deprecation clearer, but take no further action in terms of E_DEPRECATED for the forseeable future (c) Remove the warnings from the manual and undeprecate ext/mysql entirely Has 2(c) been even suggested? Not that I've seen, but having a none of the above, I want none of this option seems prudent. Except it's lets reverse the changes already made, not none of the above. I take at that 2(b) is for those advocating Move to PECL with no E_DEPRECATED notices being thrown? Not really. We can't really unbundle and move to PECL without deprecating first anyway, IMO. It's basically the option for no real change but clarifying the manual wording, since nobody seems satisfied with it. No other extension was deprecated before moving to PECL, so why the extra hurt for ext/mysql? As I've said before, it doesn't makes sense to have it throw notices while it's in core, then no longer throw notices once moved to PECL. If the plan is to drop it completely, and not move it to PECL, then deprecation notices do make sense as there's no other recourse once the extension is removed. In that case we really should have 3 questions: Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no) Should ext/mysql be moved to PECL or dropped completely in the future (PECL/dropped) Should the manual text be changed to make soft deprecation clearer? (yes/no) Or, to put it another way from where I sit: the too hard, let's make a decision after stringing people along longer option. Adam Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On 11/20/2012 09:51 PM, Adam Harvey wrote: On 21 November 2012 13:45, Stas Malyshev smalys...@sugarcrm.com wrote: Proposal: I propose we revert this change. Future consideration might I see no reason to revert the change and keep dragging around the GUIDs. Data URLs are much better and cleaner solution, and only reasons not to do it are purely bureaucratic, for which I don't care much. We could keep the functions, but what these functions would do? The issue I have with this is just that we don't seem to be making much of an effort to stick to the promises we've made around BC when it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? We also have to apply common sense here. You are implicitly comparing ext/mysql which millions of sites use to these logo functions which 0 sites use. The one and only reason we had to add them over simply doing an img src tag was because people complained that we were tracking them. It is obviously way better to just stick an img src tag in your page if you want to put a php logo on there so there is no reason for people to use these functions and people don't. We weren't even going to document them actually, but someone did for completeness sake, I guess. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
Hi! The issue I have with this is just that we don't seem to be making much of an effort to stick to the promises we've made around BC when We make a lot of effort to do this. But it does not mean we should be blindly and stupidly following the rigid rules even when it makes zero sense in practice. it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Exactly because in practice it is not important. So on one side, you have making PHP better without any practical downside. On the other side, you have delaying making PHP better, but feeling good about strictly following bureaucratic rules. I prefer the former. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. And when they don't. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Expose zend_message_dispatcher_p
[see below] On Wed, Nov 21, 2012 at 6:39 AM, Laruence larue...@php.net wrote: Hey: This problem come out when I was figuring a performance issue of Yaf_Loader. Yaf provides a autoloader like PSR0, when doing a classes autoloading. it used to: 1. stat the file, if file does not exists, return 2. zend_compile_file this is okey when you run yaf without opcode cache. but when you run yaf with opcode cache, the first stat syscall become a little waste. You should just use virtual_realpath() or tsrm_realpath() instead of stat(). They must utilise realpath cache and avoid stat() calls. Thanks. Dmitry. since opcode cache always hook the zend_compile_file, and compile the file from cache. so, I changed the autoload to: 1. zend_compile_file 2. if compile failed, then return. but, zend_compile_file will throw warning if the file doesn't exists via zend_message_dispatcher_p so if zend_message_dispatcher_p is ZEND_API, then I can avoid using such mess codes: https://github.com/laruence/php-yaf/blob/master/yaf_loader.c#L377 what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Where did the _logo_ functions go?
On Nov 20, 2012, at 10:34 PM, Stas Malyshev wrote: Hi! The issue I have with this is just that we don't seem to be making much of an effort to stick to the promises we've made around BC when We make a lot of effort to do this. But it does not mean we should be blindly and stupidly following the rigid rules even when it makes zero sense in practice. We made sense, and are not being blind and stupid. You may disagree but I don't understand why this discussion has to become so harsh. it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Exactly because in practice it is not important. So on one side, you have making PHP better without any practical downside. On the other side, you have delaying making PHP better, but feeling good about strictly following bureaucratic rules. I prefer the former. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. And when they don't. It's the inconsistency that bothers me. I think a rule like Never remove a ~function without it first emitting E_DEPRECATED can be followed 100% of the time, and don't see this as a bureaucratic rule but instead think this consistency would make PHP better. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where did the _logo_ functions go?
On 21 November 2012 14:34, Stas Malyshev smalys...@sugarcrm.com wrote: it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Exactly because in practice it is not important. Actually, I'm going to retract my statement, and here's why: http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php Let's set aside that this is terribly misguided code[0]. If that was a good enough reason to remove functionality willy-nilly, I could have saved myself a lot of e-mails on the ext/mysql front. But (to my horror) users are actually using php_logo_guid() in the wild. I haven't searched for the other functions, but I assume there are cases where they're used too. And it's not just one WordPress plugin. Nanoweb[1] calls php_logo_guid() on its demo page[2]. ErfurtWiki[3] has a similar demo page[4]. There are other projects of dubious provenance on Ohloh that call it too. It may only be a handful of projects, none of which any of us have probably ever heard of, or will ever hear a complaint from, but I bet those projects are important to their creators. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. The rules are there to protect developers from having functions dropped out from under them without warning. I don't see the problem with reverting this on the 5.5 branch only, adding E_DEPRECATED warnings to the appropriate places, and making the first item in the master UPGRADING guide for 5.6 be that these functions were removed. Adam [0] Hell, it won't even decrypt or encrypt properly on April 1, which is entertaining. [1] The PHP Web Server: http://nanoweb.si.kz/ [2] http://nanoweb-instant.googlecode.com/svn/trunk/www/vhosts/www.cgidemo.com/index.php [3] http://sourceforge.net/projects/erfurtwiki/ [4] https://erfurtwiki.svn.sourceforge.net/svnroot/erfurtwiki/trunk/ewiki/examples/zendwiki.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Expose zend_message_dispatcher_p
On Wed, Nov 21, 2012 at 2:35 PM, Dmitry Stogov dmi...@zend.com wrote: [see below] On Wed, Nov 21, 2012 at 6:39 AM, Laruence larue...@php.net wrote: Hey: This problem come out when I was figuring a performance issue of Yaf_Loader. Yaf provides a autoloader like PSR0, when doing a classes autoloading. it used to: 1. stat the file, if file does not exists, return 2. zend_compile_file this is okey when you run yaf without opcode cache. but when you run yaf with opcode cache, the first stat syscall become a little waste. You should just use virtual_realpath() or tsrm_realpath() instead of stat(). They must utilise realpath cache and avoid stat() calls. Hey: Thanks, Dmitry, actually, I didn't do like that is because by default, realpath cache has 2min ttl. but, after a second think, I think this will be better than my current tricky implementation.. I will try in this way :) thanks Thanks. Dmitry. since opcode cache always hook the zend_compile_file, and compile the file from cache. so, I changed the autoload to: 1. zend_compile_file 2. if compile failed, then return. but, zend_compile_file will throw warning if the file doesn't exists via zend_message_dispatcher_p so if zend_message_dispatcher_p is ZEND_API, then I can avoid using such mess codes: https://github.com/laruence/php-yaf/blob/master/yaf_loader.c#L377 what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
