Re: [PHP-DEV] Change all XFAIL tests to FAIL
30 марта 2012 г. 22:16 пользователь Christopher Jones christopher.jo...@oracle.com написал: On 3/29/12 3:00 PM, Alexey Shein wrote: Hi, internals! I've got a suggestion about refactoring our tests suite. I'd like to remove XFAIL institution and mark all failing tests just as FAIL. XFAIL has a problem that it hides attention from failing tests depending on not yet fixed bugs (most important), not yet implemented features (less important). Failed tests should make pain. They should bug you every day until you go and fix them. XFAILs serve now as a pain-killers, we've got about 50 of them in the repo, so devs (I assume) think this way: It's failing, but it's EXPECTED to fail, so let's leave it as is. That's wrong thinking. Either tests are correct and if they fail you should fix the code and leave them failed until the code is fixed, or, if the tests are incorrect - fix the tests or remove them completely. The XFAIL mechanism reflects the reality of open source that not all bugs are fixed. We need a simple, low maintenance way to have a 'clean' testsuite shipped which exhibits minimal noise so that users don't waste time investigating known failures. I'm trying to solve 2 different problems here: 1) Separate clean testsuite (new failed bugs) from known failed bugs (as you said) - XFAIL solves that 2) Keep devs' attention on known failures - XFAIL doesn't solve that. You remember about them when you run tests and if you want make attention at them. What I propose is a single *daily* newsletter saying Hey, guys! We still have XFAIL bugs on 5.3 list bugs, 5.4 list bugs and master list bugs. Bye! That will make some pressure, especially if those bugs have maintainers. We do get constant notification of bugs assigned to us. I don't believe it has any impact on the fix rate. Hmm, that's different. You get a notification if there's some change on that bug (new comment/state changed/patch etc.). If bug didn't change for years, you won't get any notifications - it's more likely you forget about it. XFAIL also allows end users to see when something has broken that used to work. Maybe, but not the best way, since it involves manual editing phpt source FAIL-XFAIL. Jenkins build failure notification solves it better. If the system is being overused, feel free to call people out on it. I don't think it should be used for unimplemented features long term. XFAIL is a simple mechanism. Anything different like moving tests to a special 'failed' directory adds burden. I don't belive we have extra cycles for this, but would be happy to be proved wrong. Agree, that's a lot of work, need to try something else. The problem is here what bugs need to be solved for release to be made?. We need to separate these somehow. XFAIL doesn't really helps here since it's just bugs that are hard to solve and it doesn't enforce any priority here. For 5.4 release Stas used wiki for keeping track of bugs stopping the release. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] is_subclass_of() confusion
Hi Stas I'm not sure what is the correct behavior, but if is_subclass_of() is behaving wrong, it is better to be fixed before 5.4.1 (and 5.3.11 also) https://bugs.php.net/bug.php?id=61526 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: bugs needs fix before 5.4.1
On 3/30/12 7:27 PM, Yasuo Ohgaki wrote: Hi Stas, Just FYI. Following bugs are needed to be fixed before 5.4.1, I think. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. -- 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] Change all XFAIL tests to FAIL
On 03/30/2012 11:25 PM, Alexey Shein wrote: Hmm, that's different. You get a notification if there's some change on that bug (new comment/state changed/patch etc.). If bug didn't change for years, you won't get any notifications - it's more likely you forget about it. That's not true. There is a weekly reminder email if you have outstanding open bugs assigned to you. Although I haven't seen one for a little while, so we may finally have given up on that since it was completely ineffective. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
Hi! 2) Keep devs' attention on known failures - XFAIL doesn't solve that. You remember about them when you run tests and if you want make attention at them. Which devs you are referring to? Why you assume their attention needs help? What I propose is a single *daily* newsletter saying Hey, guys! We still have XFAIL bugs on 5.3 list bugs, 5.4 list bugs and master list bugs. Bye! That will make some pressure, especially if those bugs have maintainers. I would not subscribe to this and would not read this. Would you? Why? We know we have technical debt. It's not a secret. What we need is not more harassment but more people fixing that debt. Spamming whole list with messages that nobody would read is not the solution. -- 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] Change all XFAIL tests to FAIL
Hi! That's not true. There is a weekly reminder email if you have outstanding open bugs assigned to you. Although I haven't seen one for a little while, so we may finally have given up on that since it was completely ineffective. Actually, this one I'd like to keep - though I'd prefer monthly one. -- 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: bugs needs fix before 5.4.1
Hi, Thanks for reply. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. We should improve doc, it's confusing. https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. Since the result became opposite, I think it should be noted in migration doc and array page. I'll do that now. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/3/31 Stas Malyshev smalys...@sugarcrm.com: On 3/30/12 7:27 PM, Yasuo Ohgaki wrote: Hi Stas, Just FYI. Following bugs are needed to be fixed before 5.4.1, I think. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. -- 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] 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
在 2012年3月31日星期六，下午3:31，Stas Malyshev 写道： On 3/30/12 7:27 PM, Yasuo Ohgaki wrote: Hi Stas, Just FYI. Following bugs are needed to be fixed before 5.4.1, I think. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. If is set to false does it means the first parameter can't be string? Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. if string will not be a String Class in 5.* I think it's ok to do like this. eg: callable and many mixed paramter. what do you think? https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. -- 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] 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
Hi, From the NEWS file : + . Fixed bug #55475 (is_a() triggers autoloader, new optional 3rd argument to + is_a and is_subclass_of). (alan_k) The 3rd argument is add to let user choose autoload or not, but not a string or not. so maybe we can make it more clear. -- reeze 已使用 Sparrow (http://www.sparrowmailapp.com/?sig) 发送 在 2012年3月31日星期六，下午3:58，reeze 写道： 在 2012年3月31日星期六，下午3:31，Stas Malyshev 写道： On 3/30/12 7:27 PM, Yasuo Ohgaki wrote: Hi Stas, Just FYI. Following bugs are needed to be fixed before 5.4.1, I think. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. If is set to false does it means the first parameter can't be string? Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. if string will not be a String Class in 5.* I think it's ok to do like this. eg: callable and many mixed paramter. what do you think? https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. -- 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: 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
2012/3/31 reeze reeze@gmail.com:
在 2012年3月31日星期六，下午3:31，Stas Malyshev 写道：
On 3/30/12 7:27 PM, Yasuo Ohgaki wrote:
Hi Stas,
Just FYI.
Following bugs are needed to be fixed before 5.4.1, I think.
https://bugs.php.net/bug.php?id=61526
Which is right, doc or code?
Both. The parameter means that first argument (object) can be a string,
and if it is, it will be passed to autoloader to find the class. See bug
#55475 for the discussion.
If is set to false does it means the first parameter can't be string?
Can't we just make the last parameter to autoload=true|false.
if the first parameter is a string then try to find the class if not try
autoloadding.
if string will not be a String Class in 5.* I think it's ok to do like
this. eg: callable and many mixed paramter.
what do you think?
You're right.
I've read too many bug reports today and confused :)
?php
class Super {}
class Sub extends Super {}
// By default, 1st parameter may be string and treated as class name.
var_dump(is_subclass_of('Sub', 'Super')); // true
// Explicitly allow string as class name
var_dump(is_subclass_of('Sub', 'Super', true)); // true
// Do not allow string as a 1st parameter, so false.
var_dump(is_subclass_of('Sub', 'Super', false)); // false
?
Therefore, 3rd parameter works for Not allowing class name, but
it cannot be used to restrict autoloading.
Am I missing something? I'll read the report Stas mentioned from now.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
2012/3/31 reeze reeze@gmail.com: Hi, From the NEWS file : + . Fixed bug #55475 (is_a() triggers autoloader, new optional 3rd argument to +is_a and is_subclass_of). (alan_k) The 3rd argument is add to let user choose autoload or not, but not a string or not. so maybe we can make it more clear. It seems 3rd parameter is used only to deny class name(string). This certainly prevents autoloading, but I'm not sure if this is intended. I'll read the bug report and figure out. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Providing sandboxed versions of include and require language constructs
On Tue, Mar 6, 2012 at 2:34 AM, Adam Jon Richardson adamj...@gmail.comwrote:
Plugins are a big deal (see
http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a
recent example.) In this era of mashups and breakneck innovation,
developers must rely on vast amounts of code they've never seen, let alone
audited. Wordpress, Drupal, and many other tools developed in PHP make
plugin development easy and extremely powerful. While these tools
constantly work to improve security (and, at least relatively, do a solid
job most of the time), there remains significant challenges due to globally
accessible functions that allow manipulation of the environment (files,
DB's, networking, etc.) Any plugin can use these global functions to work
around the security restrictions imposed by the framework, library, or CMS.
While code audits can locate the offending scripts, this is a challenging
task, both in terms of time AND abilities. Languages and/or environments
that can mitigate these issues for the developer, while far from fool
proof, do offer real value on the security front. Lua provides the ability
for developers to limit the functions available in the current environment:
http://lua-users.org/wiki/SandBoxes
PHP does have an extension that offers several forms of sandboxing:
runkit. However, it's often not available in shared host environments.
The include (and require) construct is the front door for any plugin code.
What if PHP offered functions that implemented sandboxed versions of the
include and require language constructs (e.g.,
included_restricted('file/path', $functions = array('file',
'file_get_contents')))? Functional specs could include:
1) Internal functions seen as universally safe would by default be allowed
(e.g, str_replace(), array_pop(), etc.)
2) Unsafe internal functions would have to be explicitly declared (e.g.,
file(), stream_*, etc.)
3) Any includes or requires within the sandboxed code would be forced to
meet the same restrictions. (tricky)
4) Code containing unsafe functions not included in the whitelist would
raise an error.
Hi,
I've been thinking through the idea of sandboxed versions of the include
and require language constructs, and here are some more ideas.
Some expressed concerns about how difficult sandboxing is to get right.
Reflecting on this, I agree that the difficulty is extreme. However, it's
precisely because of this difficulty that this type of language feature
would hold much value.
Some expressed concerns about how difficult sandboxing could make it to
develop plugins in applications like Drupal, Wordpress, etc. I don't see
this as an issue, as many plugins need only very primitive features (e.g.,
a Wordpress plugin that is adding Google Analytics functionality to a
blog), those plugins that require more access can be granted more access
through the function's whitelist, and there would still be the standard
(non-sandboxed) versions of require and include that can be used.
Sandboxing should prevent reading/writing from/to any part of the
environment not purposely exposed by the application/framework. That is to
say that the application/framework should have the ability to govern the
access to php settings, files, databases, etc. This would require limiting
PHP code within included files by:
- Raising an error for calls to functions not whitelisted (either by
default or manually in the function call.)
- Raising an error for attempts to instantiate object interfaces not
whitelisted (some extensions like mysqli have function- and object-based
interfaces.) Of note, the application/framework would be able to pass in an
object interface for use within the included file.
An example of the code using a sandboxed include could be as follows for a
plugin that uses the mysql PDO extension:
sandboxed_include('file/path', array('SANDBOX_PDO','SANDBOX_MYSQL_PDO'));
I've started a simple list of safe (whitelisted) vs unsafe
extensions/function/objects:
http://adamjonrichardson.com/php-sandbox-safety.php
Of note, it's a very quick, limited start. I'll spend some time over the
next few weeks going through extension-by-extension, function-by-function
looking to improve the list. I just wanted to put the idea out there for
more feedback while I'm working on more ideas.
Additionally, while the sandboxes would largely be broken up by extension
(as categorized in the PHP website), some exceptions did seem reasonable
(e.g., while most date functions are OK, few included files should need the
ability adjust the default timezone for the app.)
Thanks for the feedback,
Adam
Re: [PHP-DEV] Change all XFAIL tests to FAIL
31 марта 2012 г. 12:50 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! 2) Keep devs' attention on known failures - XFAIL doesn't solve that. You remember about them when you run tests and if you want make attention at them. Which devs you are referring to? Why you assume their attention needs help? Every developer on this list including core and non-core. There are a lot of people reading this list, that's clearly seen by lengthy feature discussions. If you're well-aware of current PHP problems (I assume you're the best person to ask about, since you're RM), others may even don't have a glue about that. By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. What I propose is a single *daily* newsletter saying Hey, guys! We still have XFAIL bugs on 5.3 list bugs, 5.4 list bugs and master list bugs. Bye! That will make some pressure, especially if those bugs have maintainers. I would not subscribe to this and would not read this. Would you? Why? I don't mean a separate mailing list, but a letter to this list, internals. If i'm already here, I'd read it. If you think that daily is too much - let's make it weekly, but it should come every week, not just once or twice. If it annoys you too much or you think it's useless for you - you always can tune your spam filter. I'd read it, since I like writing/fixing tests in my spare time, maybe that letter would contain some tests I can easily fix (since I'm not good C-developer I work primarily on tests), or my investigation on problem will help somebody to make a patch. We know we have technical debt. It's not a secret. What we need is not more harassment but more people fixing that debt. Spamming whole list with messages that nobody would read is not the solution. You can't interest more people if they are not aware of your problems. That's why personal reminders won't work good here - if only bug maintainer will be notified, nobody else will recall that bug. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
31 марта 2012 г. 12:34 пользователь Rasmus Lerdorf ras...@lerdorf.com написал: On 03/30/2012 11:25 PM, Alexey Shein wrote: Hmm, that's different. You get a notification if there's some change on that bug (new comment/state changed/patch etc.). If bug didn't change for years, you won't get any notifications - it's more likely you forget about it. That's not true. There is a weekly reminder email if you have outstanding open bugs assigned to you. Although I haven't seen one for a little while, so we may finally have given up on that since it was completely ineffective. Ok, we have a weekly reminder to bug maintainers (that maybe not working). That's a bit different, I'm talking about public email about failed tests - if bug is closed, maintainer won't get a notfication and, if bug is reopened, only maintainer will get a notification, not everybody on list. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
Hi, This is my suggestion for is_subclass_of() doc fix. I've already committed. If anyone want to improve, please do. https://gist.github.com/2260846 I would like to allow string class name always and only prevent autoloading, but I don't care much. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
Hi! If is set to false does it means the first parameter can't be string? It can. But it won't be seen as a class name, but rather as a string, that is not an object that is an instance of a subclass of anything, so it will return false. Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. We discussed all the solutions already and chose this one, please see discussion on the list and the bug I've referred to. I see no point in going through the same discussion again. -- 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] Change all XFAIL tests to FAIL
On 03/31/2012 01:21 AM, Alexey Shein wrote: 31 марта 2012 г. 12:50 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! 2) Keep devs' attention on known failures - XFAIL doesn't solve that. You remember about them when you run tests and if you want make attention at them. Which devs you are referring to? Why you assume their attention needs help? Every developer on this list including core and non-core. There are a lot of people reading this list, that's clearly seen by lengthy feature discussions. If you're well-aware of current PHP problems (I assume you're the best person to ask about, since you're RM), others may even don't have a glue about that. By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. Every developer on this list builds PHP at least daily and also runs make test at least every few days so they are well aware of the status of the tests. I think you will find that there aren't as many developers here as you think and only the developers are actually going to fix stuff. An alert on a brand new test failure along with the commit that caused it, that would be useful and that is what the Jenkins work will eventually bring us. A list of the same xfails that all of us are painfully aware of isn't useful. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
在 2012年3月31日星期六，下午4:35，Stas Malyshev 写道： Hi! If is set to false does it means the first parameter can't be string? It can. But it won't be seen as a class name, but rather as a string, that is not an object that is an instance of a subclass of anything, so it will return false. Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. We discussed all the solutions already and chose this one, please see discussion on the list and the bug I've referred to. I see no point in going through the same discussion again. Thanks for your kindly explanation and yohagaki's doc update I've got it.
[PHP-DEV] Re: com php-src: Merge branch 'PHP-5.3' into PHP-5.4: main/SAPI.h
On 2012-03-31, David Soria Parra d...@php.net wrote: Commit:3bf53aa911e1e2128a11aee45c126000635de006 Author:David Soria Parra d...@php.net Sat, 31 Mar 2012 09:34:25 +0200 Parents: aa774a51d5c45b98103e0f67914d4c0b152e80ae ff8be9845f14a8156e7551033c2e98dad459f6fd Branches: PHP-5.4 master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=3bf53aa911e1e2128a11aee45c126000635de006 Log: Merge branch 'PHP-5.3' into PHP-5.4 * PHP-5.3: Cleanup Safe Mode related comment in SG(request_info) Changed paths: MM main/SAPI.h The diff is strange. Git and Gitweb show both that just the comment changed. The diff here displays the overall differneces between SAPI.h in PHP-5.3 and PHP-5.4 and not what I actually changed. I verified that the SAPI.h on the PHP-5.4 branch just had the comment removed. Diff: 3bf53aa911e1e2128a11aee45c126000635de006 diff --combined main/SAPI.h index f868f85,9a063d3..8f2536b --- a/main/SAPI.h +++ b/main/SAPI.h @@@ -105,7 -105,6 +105,6 @@@ typedef struct /* this is necessary for the CGI SAPI module */ char *argv0; - /* this is necessary for Safe Mode */ char *current_user; int current_user_length; @@@ -129,11 -128,8 +128,11 @@@ typedef struct _sapi_globals_struct long post_max_size; int options; zend_bool sapi_started; -time_t global_request_time; +double global_request_time; HashTable known_post_content_types; +zval *callback_func; +zend_fcall_info_cache fci_cache; +zend_bool callback_run; } sapi_globals_struct; @@@ -193,9 -189,9 +192,9 @@@ SAPI_API void sapi_handle_post(void *ar SAPI_API int sapi_register_post_entries(sapi_post_entry *post_entry TSRMLS_DC); SAPI_API int sapi_register_post_entry(sapi_post_entry *post_entry TSRMLS_DC); SAPI_API void sapi_unregister_post_entry(sapi_post_entry *post_entry TSRMLS_DC); -SAPI_API int sapi_register_default_post_reader(void (*default_post_reader)(TSRMLS_D)); -SAPI_API int sapi_register_treat_data(void (*treat_data)(int arg, char *str, zval *destArray TSRMLS_DC)); -SAPI_API int sapi_register_input_filter(unsigned int (*input_filter)(int arg, char *var, char **val, unsigned int val_len, unsigned int *new_val_len TSRMLS_DC), unsigned int (*input_filter_init)(TSRMLS_D)); +SAPI_API int sapi_register_default_post_reader(void (*default_post_reader)(TSRMLS_D) TSRMLS_DC); +SAPI_API int sapi_register_treat_data(void (*treat_data)(int arg, char *str, zval *destArray TSRMLS_DC) TSRMLS_DC); +SAPI_API int sapi_register_input_filter(unsigned int (*input_filter)(int arg, char *var, char **val, unsigned int val_len, unsigned int *new_val_len TSRMLS_DC), unsigned int (*input_filter_init)(TSRMLS_D) TSRMLS_DC); SAPI_API int sapi_flush(TSRMLS_D); SAPI_API struct stat *sapi_get_stat(TSRMLS_D); @@@ -211,7 -207,7 +210,7 @@@ SAPI_API int sapi_force_http_10(TSRMLS_ SAPI_API int sapi_get_target_uid(uid_t * TSRMLS_DC); SAPI_API int sapi_get_target_gid(gid_t * TSRMLS_DC); -SAPI_API time_t sapi_get_request_time(TSRMLS_D); +SAPI_API double sapi_get_request_time(TSRMLS_D); SAPI_API void sapi_terminate_process(TSRMLS_D); END_EXTERN_C() @@@ -240,8 -236,8 +239,8 @@@ struct _sapi_module_struct char *(*read_cookies)(TSRMLS_D); void (*register_server_variables)(zval *track_vars_array TSRMLS_DC); -void (*log_message)(char *message); -time_t (*get_request_time)(TSRMLS_D); +void (*log_message)(char *message TSRMLS_DC); +double (*get_request_time)(TSRMLS_D); void (*terminate_process)(TSRMLS_D); char *php_ini_path_override; @@@ -254,7 -250,6 +253,7 @@@ char *executable_location; int php_ini_ignore; +int php_ini_ignore_cwd; /* don't look for php.ini in the current directory */ int (*get_fd)(int *fd TSRMLS_DC); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
2012/3/31 Stas Malyshev smalys...@sugarcrm.com: Hi! That's not true. There is a weekly reminder email if you have outstanding open bugs assigned to you. Although I haven't seen one for a little while, so we may finally have given up on that since it was completely ineffective. Actually, this one I'd like to keep - though I'd prefer monthly one. +1 for monthly. Today, I assigned many bugs to myself. None is not good, weekly is too much. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
hi, On Sat, Mar 31, 2012 at 11:56 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: +1 for monthly. It is the case already and I get them regularly. 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] (*PATCH*) getters/setters Implementation
The patches are applied to this fork if anyone wants to check it out: https://github.com/cpriest/php-src -Original Message- From: Clint M Priest [mailto:cpri...@zerocue.com] Sent: Thursday, March 29, 2012 8:14 PM To: internals@lists.php.net Subject: RE: [PHP-DEV] (*PATCH*) getters/setters Implementation Thanks for the feedback, I'll take care of some of these. What did you mean about the out of sync regarding naming? With the unexpected values to the methods I'm not sure what you mean, there are no 'expected values' to be passed. For the auto-backed properties it would be assigned to whatever value was being passed, null or whatever. For the non auto-backed properties it would depend on the user-supplied getter/setter implementation. Am I missing something here? Regarding the open questions on read-only/write-only I don't think they are strictly necessary any longer. The original RFC had them for enforcing a value to be read only but it would be equivalent of setting an accessor with just a getter and final although it would allow for it to be over-ridden. Are the read-only/write-only tags desired? I think the test cases that are present are complete, I could not think of any further tests to write or I would have written them, any suggestions? I'll update the RFC with backward compatibility comments though I believe there are none, anyone else see any backward compatibility issues? -Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Thursday, March 29, 2012 1:14 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] (*PATCH*) getters/setters Implementation On 03/28/2012 08:13 PM, Clint M Priest wrote: What are the next steps to get this added to some future release? Attached is a patch against ~/trunk A couple of brief comments from the sidelines without having followed previous discussion in detail: - The RFC appears to have open questions e.g about the need for readonly etc keywords - The tests and RFC are out of sync regarding naming, e.g. readonly vs read-only - The RFC makes no mention of backward compatibility issues - Did I miss seeing tests that pass in unexpected values to the methods? - I would expect a larger number of tests overall when the feature is merged/completed. - If these are indeed magic methods they need __ prefixes, so consider the names __getter and __setter - I'd suggest biting the github bullet and creating your own PHP fork with your patches. People will be able to test and you might get more feedback. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (*PATCH*) getters/setters Implementation
31 марта 2012 г. 18:19 пользователь Clint M Priest cpri...@zerocue.com написал: The patches are applied to this fork if anyone wants to check it out: https://github.com/cpriest/php-src It would be easier to discuss/review your patch if you'd make pull request: https://wiki.php.net/vcs/gitworkflow#workflow_for_external_contributors Thank you. -Original Message- From: Clint M Priest [mailto:cpri...@zerocue.com] Sent: Thursday, March 29, 2012 8:14 PM To: internals@lists.php.net Subject: RE: [PHP-DEV] (*PATCH*) getters/setters Implementation Thanks for the feedback, I'll take care of some of these. What did you mean about the out of sync regarding naming? With the unexpected values to the methods I'm not sure what you mean, there are no 'expected values' to be passed. For the auto-backed properties it would be assigned to whatever value was being passed, null or whatever. For the non auto-backed properties it would depend on the user-supplied getter/setter implementation. Am I missing something here? Regarding the open questions on read-only/write-only I don't think they are strictly necessary any longer. The original RFC had them for enforcing a value to be read only but it would be equivalent of setting an accessor with just a getter and final although it would allow for it to be over-ridden. Are the read-only/write-only tags desired? I think the test cases that are present are complete, I could not think of any further tests to write or I would have written them, any suggestions? I'll update the RFC with backward compatibility comments though I believe there are none, anyone else see any backward compatibility issues? -Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Thursday, March 29, 2012 1:14 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] (*PATCH*) getters/setters Implementation On 03/28/2012 08:13 PM, Clint M Priest wrote: What are the next steps to get this added to some future release? Attached is a patch against ~/trunk A couple of brief comments from the sidelines without having followed previous discussion in detail: - The RFC appears to have open questions e.g about the need for readonly etc keywords - The tests and RFC are out of sync regarding naming, e.g. readonly vs read-only - The RFC makes no mention of backward compatibility issues - Did I miss seeing tests that pass in unexpected values to the methods? - I would expect a larger number of tests overall when the feature is merged/completed. - If these are indeed magic methods they need __ prefixes, so consider the names __getter and __setter - I'd suggest biting the github bullet and creating your own PHP fork with your patches. People will be able to test and you might get more feedback. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: com php-src: Merge branch 'PHP-5.3' into PHP-5.4: main/SAPI.h
On 03/31/2012 01:52 AM, David Soria Parra wrote: On 2012-03-31, David Soria Parra d...@php.net wrote: Commit:3bf53aa911e1e2128a11aee45c126000635de006 Author:David Soria Parra d...@php.net Sat, 31 Mar 2012 09:34:25 +0200 Parents: aa774a51d5c45b98103e0f67914d4c0b152e80ae ff8be9845f14a8156e7551033c2e98dad459f6fd Branches: PHP-5.4 master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=3bf53aa911e1e2128a11aee45c126000635de006 Log: Merge branch 'PHP-5.3' into PHP-5.4 * PHP-5.3: Cleanup Safe Mode related comment in SG(request_info) Changed paths: MM main/SAPI.h The diff is strange. Git and Gitweb show both that just the comment changed. The diff here displays the overall differneces between SAPI.h in PHP-5.3 and PHP-5.4 and not what I actually changed. Right, that's what I have been complaining about as well. The diffs in emails on merges do not reflect reality. It happens on all merges to code that is different between 5.3 and 5.4. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Confusing Windows Users 101...the download page is UNUSABLE.
I've been writing software for Windows in Visual Studio since forever and also know user-land PHP like the back of my hand and, even after a few Google searches, I'm still scratching my head over which PHP Windows binary download I want to use. If *I* can't figure out which version is appropriate, neither can the average web developer. Fixing the Windows binary download page so that it is USABLE by the average user should be priority #1. If I want to download PHP, I usually go here: http://www.php.net/downloads.php Which in turn, because I want Windows binaries, now takes me here: http://windows.php.net/download/ Here are the specific issues with the Windows binary download page: * The Which version do I choose? box is confusing, out of date, doesn't actually address all the real questions users will have, and most users will just give up before getting to that box. Even if they do get to the box, the end result will be an even more confused/confounded user. The box should, at the very least, explain in clear English the difference between the Non-Thread Safe and Thread Safe builds. Also, assume that most users won't even know what Visual Studio even is. Hold the user's hand here and you'll have less cruft on the mailing lists later. * The ordering of the downloads seems backwards. But until you get the Which version do I choose? box fixed, I won't be able to determine this. * The Select an option to direct access... dropdown is completely useless. * The previous page says Windows binaries and installers. In that context, the user mentally asks: Why is there source code on the next page? And why is source code listed first if I'm after binaries? And, last, but HARDLY least. Listed last because this item requires rethinking and redesigning the entire Windows binary download page: * The two column layout is confusing and not really necessary. If users are not going to know what they need (which they won't) and you are going to maintain a complex set of binaries (which it appears there will be for some time), consider making a wizard instead. First step: Choose a version of PHP. This step is pretty self-explanatory but affords explaining which version the user should choose and why. Second step: Choose a build type. In this step, explain the differences between the builds and then *RECOMMEND A BUILD TYPE!* Third step: Download. In this step, include the links to the appropriate VC++ runtimes and Apache in addition to the correct downloads for the previously selected version and build type. This approach also affords adding a What do I do next? section to be on the download page to get the user started on the right path if they've never used the PHP binaries or PHP before. Maybe also inject a short blurb somewhere on the download page discussing ZIP vs. Installer vs. Debug Pack. -- Thomas Hruska CubicleSoft President Barebones CMS is a high-performance, open source content management system for web developers operating in a team environment. An open source CubicleSoft initiative. Your choice of a MIT or LGPL license. http://barebonescms.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Confusing Windows Users 101...the download page is UNUSABLE.
On 2012-03-31, Thomas Hruska thru...@cubiclesoft.com wrote: I've been writing software for Windows in Visual Studio since forever and also know user-land PHP like the back of my hand and, even after a few Google searches, I'm still scratching my head over which PHP Windows binary download I want to use. If *I* can't figure out which version is appropriate, neither can the average web developer. Fixing the Windows binary download page so that it is USABLE by the average user should be priority #1. Thank you for letting us know about the potential problems of the windows download site. Feedback is alwahys appreciated. Why not go ahead and help out? Feel free to fork the windows website on https://github.com/php/web-windows and open a pull request. Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Confusing Windows Users 101...the download page is UNUSABLE.
hi, On Sat, Mar 31, 2012 at 6:14 PM, Thomas Hruska thru...@cubiclesoft.com wrote: Fixing the Windows binary download page so that it is USABLE by the average user should be priority #1. Here are the specific issues with the Windows binary download page: * The Which version do I choose? box is confusing, out of date, doesn't actually address all the real questions users will have, and most users will just give up before getting to that box. Even if they do get to the box, the end result will be an even more confused/confounded user. The box should, at the very least, explain in clear English the difference between the Non-Thread Safe and Thread Safe builds. Also, assume that most users won't even know what Visual Studio even is. Hold the user's hand here and you'll have less cruft on the mailing lists later. Right VC6 could be removed. However I kept it so that users still downloading older PHP 5.2 or 5.3 still needs this notice, it has been proven to be useful. * The ordering of the downloads seems backwards. But until you get the Which version do I choose? box fixed, I won't be able to determine this. * The Select an option to direct access... dropdown is completely useless. Right, now that we have only two kind of binaries, NTS (fastcgi) or TS (apache SAPIs and co). But in a few months, that wil change again with the re introduciton of the x64 binaries. * The previous page says Windows binaries and installers. In that context, the user mentally asks: Why is there source code on the next page? And why is source code listed first if I'm after binaries? The box, clearly visible, contains the binary. We can indeed move the src link down the box. And, last, but HARDLY least. Listed last because this item requires rethinking and redesigning the entire Windows binary download page: Feel free to provide a patch for a wizard. btw, I, for one, am not BLIND. Thanks. 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] Change all XFAIL tests to FAIL
On Fri, 2012-03-30 at 10:16 -0700, Christopher Jones wrote: The XFAIL mechanism reflects the reality of open source that not all bugs are fixed. I wonder what that has to do with open source ... besides maybe TeX there's no non-trivial bug free software. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
On Sat, 2012-03-31 at 13:27 +0500, Alexey Shein wrote: Ok, we have a weekly reminder to bug maintainers (that maybe not working). Those are working. At least for me :-) There was some trouble with mails for individual changes, but recently I got an you have been assigned mail, too. That's a bit different, I'm talking about public email about failed tests - if bug is closed, maintainer won't get a notfication and, if bug is reopened, only maintainer will get a notification, not everybody on list. Which can also be a lot, many test, unfortunately, are depending on the environment, like OS or external systems (library version, database configuration, etc.) and it is hard to cover all those combinations while still testing edge case conditions. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
On Sat, 2012-03-31 at 13:21 +0500, Alexey Shein wrote: By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. While many people will simply filter them out. At least that's my experience with such automated mails in different projects ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Confusing Windows Users 101...the download page is UNUSABLE.
Hi! btw, I, for one, am not BLIND. Thanks. Coincidentally, just read this: http://thingist.com/t/item/4372/ I think makes a useful reading. -- 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] Re: Confusing Windows Users 101...the download page is UNUSABLE.
Hi 2012/4/1 David Soria Parra d...@php.net: On 2012-03-31, Thomas Hruska thru...@cubiclesoft.com wrote: I've been writing software for Windows in Visual Studio since forever and also know user-land PHP like the back of my hand and, even after a few Google searches, I'm still scratching my head over which PHP Windows binary download I want to use. If *I* can't figure out which version is appropriate, neither can the average web developer. Fixing the Windows binary download page so that it is USABLE by the average user should be priority #1. Thank you for letting us know about the potential problems of the windows download site. Feedback is alwahys appreciated. Why not go ahead and help out? Feel free to fork the windows website on https://github.com/php/web-windows and open a pull request. Thanks You would probably want to read these to contribute. https://wiki.php.net/vcs/gitfaq https://wiki.php.net/vcs/gitworkflow Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
1 апреля 2012 г. 0:27 пользователь Johannes Schlüter johan...@schlueters.de написал: On Sat, 2012-03-31 at 13:21 +0500, Alexey Shein wrote: By constantly publishing newsletter with failed / xfail bugs you're telling them That's our current problems. Maybe you could help us with them. This way we could convert that discussing energy into some good patches. While many people will simply filter them out. At least that's my experience with such automated mails in different projects ;-) johannes Okay, let's find it out. I've created a poll here: https://wiki.php.net/xfail_poll. Please, leave your voice. I'll close the poll in a week. Thank you. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Confusing Windows Users 101...the download page is UNUSABLE.
On Sat, Mar 31, 2012 at 1:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi 2012/4/1 David Soria Parra d...@php.net: On 2012-03-31, Thomas Hruska thru...@cubiclesoft.com wrote: I've been writing software for Windows in Visual Studio since forever and also know user-land PHP like the back of my hand and, even after a few Google searches, I'm still scratching my head over which PHP Windows binary download I want to use. If *I* can't figure out which version is appropriate, neither can the average web developer. Fixing the Windows binary download page so that it is USABLE by the average user should be priority #1. Thank you for letting us know about the potential problems of the windows download site. Feedback is alwahys appreciated. Why not go ahead and help out? Feel free to fork the windows website on https://github.com/php/web-windows and open a pull request. Thanks You would probably want to read these to contribute. https://wiki.php.net/vcs/gitfaq https://wiki.php.net/vcs/gitworkflow Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Isn't Apache still building under VC6, or have they finally switched to VC9? --Kris
[PHP-DEV] RFC: Removing PHP tags
Hi, I wrote a RFC that proposes removal of PHP tags. There is actually strong public demand for it, and I also think it is necessary to leverage PHP to a genuine, modern scripting language. http://wiki.php.net/rfc/nophptags Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing PHP tags
Removing PHP's native feature of being able to be easily embedded inside HTML and other markup languages is absolutely retrograde. Of of the biggest points in favor of PHP is that i'm able to easily do this: ul ?php foreach ($stuff as $item): ? li?php echo $item ?/li ?php endforeach; ? /ul Or this: ?xml version=1.0 ? store ?php foreach ($stuff as $item): ? product?php echo $item ?/product ?php endforeach; ? /store Without having to implement any slow-as-hell template language. It works right out of the box. Using MVC as an argument for tag removal is a clear disrespect to the language itself.
Re: [PHP-DEV] RFC: Removing PHP tags
On Mar 31, 2012, at 6:59 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Hi, I wrote a RFC that proposes removal of PHP tags. There is actually strong public demand for it, and I also think it is necessary to leverage PHP to a genuine, modern scripting language. http://wiki.php.net/rfc/nophptags I really doubt this will find much support, and note that PHP came well before ASP so that part of the RFC is factually inaccurate. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing PHP tags
What many people fail to see is that PHP is it's own templating language. It might be ugly for people used to other template languages, but it works perfectly and right out of the box. On Sat, Mar 31, 2012 at 11:24 PM, Klaus Silveira klaussilve...@php.netwrote: Removing PHP's native feature of being able to be easily embedded inside HTML and other markup languages is absolutely retrograde. Of of the biggest points in favor of PHP is that i'm able to easily do this: ul ?php foreach ($stuff as $item): ? li?php echo $item ?/li ?php endforeach; ? /ul Or this: ?xml version=1.0 ? store ?php foreach ($stuff as $item): ? product?php echo $item ?/product ?php endforeach; ? /store Without having to implement any slow-as-hell template language. It works right out of the box. Using MVC as an argument for tag removal is a clear disrespect to the language itself.
Re: [PHP-DEV] RFC: Removing PHP tags
Hi: sorry for say that, but the only benifit I can see, is save 5+ characters... thanks On Sun, Apr 1, 2012 at 10:31 AM, Klaus Silveira klaussilve...@php.net wrote: What many people fail to see is that PHP is it's own templating language. It might be ugly for people used to other template languages, but it works perfectly and right out of the box. On Sat, Mar 31, 2012 at 11:24 PM, Klaus Silveira klaussilve...@php.netwrote: Removing PHP's native feature of being able to be easily embedded inside HTML and other markup languages is absolutely retrograde. Of of the biggest points in favor of PHP is that i'm able to easily do this: ul ?php foreach ($stuff as $item): ? li?php echo $item ?/li ?php endforeach; ? /ul Or this: ?xml version=1.0 ? store ?php foreach ($stuff as $item): ? product?php echo $item ?/product ?php endforeach; ? /store Without having to implement any slow-as-hell template language. It works right out of the box. Using MVC as an argument for tag removal is a clear disrespect to the language itself. -- 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: Removing PHP tags
Ok, I'll try to fix that part. Thanks for the correction. Moriyoshi On Sun, Apr 1, 2012 at 11:29 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On Mar 31, 2012, at 6:59 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Hi, I wrote a RFC that proposes removal of PHP tags. There is actually strong public demand for it, and I also think it is necessary to leverage PHP to a genuine, modern scripting language. http://wiki.php.net/rfc/nophptags I really doubt this will find much support, and note that PHP came well before ASP so that part of the RFC is factually inaccurate. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing PHP tags
On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Ok, I'll try to fix that part. Thanks for the correction. No problem. Keeping the April 1st RFCs factually accurate is a top priority around here. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing PHP tags
Well played Moriyoshi. Well played. Brian. http://brian.moonspot.net On 3/31/12 10:02 PM, Rasmus Lerdorf wrote: On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumim...@mozo.jp wrote: Ok, I'll try to fix that part. Thanks for the correction. No problem. Keeping the April 1st RFCs factually accurate is a top priority around here. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing PHP tags
Am 01.04.2012 03:59, schrieb Moriyoshi Koizumi: Hi, I wrote a RFC that proposes removal of PHP tags. There is actually strong public demand for it, and I also think it is necessary to leverage PHP to a genuine, modern scripting language. http://wiki.php.net/rfc/nophptags nice 1st april joke signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] RFC: Removing PHP tags
-_#... Nice play ,Moriyoshi sama! Sent from my iPhone 在 2012-4-1，11:03，Rasmus Lerdorf ras...@lerdorf.com 写道： On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Ok, I'll try to fix that part. Thanks for the correction. No problem. Keeping the April 1st RFCs factually accurate is a top priority around here. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing PHP tags
On Sat, Mar 31, 2012 at 8:38 PM, Xinchen Hui larue...@gmail.com wrote: -_#... Nice play ,Moriyoshi sama! Sent from my iPhone 在 2012-4-1，11:03，Rasmus Lerdorf ras...@lerdorf.com 写道： On Mar 31, 2012, at 7:45 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Ok, I'll try to fix that part. Thanks for the correction. No problem. Keeping the April 1st RFCs factually accurate is a top priority around here. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Damnit! I just got April Fools punked for the first time since I was a kid! Now how am I supposed to look down my nose at everyone else?! Thanks a lot, Moriyoshi. Though does it count if it's still March 31st over here? ;) --Kris
