[PHP-DEV] [GSOC] Ideas?
Hi all We should probably discuss some ideas for Google Summer of Code this year. I see people have already added few to the wiki page[1] which is great and all but wikis aren't for discussions.. The plan as I see it: Discuss ideas. Draft them up on the wiki. Move them to php.net/ideas when they are solid enough. Couple of ideas I'd love the see implemented: New bugtracker for all the *.php.net projects (one-tracker-rules-them-all). - Feature requests for specific extensions/module/class/component - Documentation bug for specific extension/module/class/component - Milestones - When a FR is closed then its automatically classified as documentation problem - When a commit contains bug#n the commit message and links to the changed files (diffs) are automatically added to the report - Possibility to reply to reports (add comment, change status) via email - Notification system (i.e. watch this report) which sends email to people watching that report on changes - Monthly reminders to reporters of reports with status feedback/no feedback - No #%#$ signup required to file reports - Possibility to attach files (patch/phpt) - Developer authentication against CVS (fallback to pear/peclweb) accounts - Support for openid (i.e. users with openid don't have to fill out a completely unreadable CAPTCHA) PhD: - PDF format support - CHM format support - man format support - PEAR/Gtk themes - Create a true indexer - Implement the rest of the standard Docbook elements+attributes - Implement default themes for all formats - Support for dbhtml processing instructions Random other ideas (most probably too small): - openid extension - threaded run-tests.php and graphical stats - mirror-test bot rewrite - automatically run relevant tests on new commit (i.e commits to ext/foo triggers test run for ext/foo/tests) - daily/weekly buildfailure mails to internals@ (win/linux/solaris/bsd/mac/..) - doxygen-to-phpdoc/docbook - user-submitted-coverage to gcov - reST to html/docbook parser - translation tool allowing users to suggest better translations ... So, what do you guys think? Have any ideas? -Hannes [1] http://wiki.php.net/gsoc/2008 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [GSOC] Ideas?
On Sun, Mar 9, 2008 at 4:17 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: Hi all We should probably discuss some ideas for Google Summer of Code this year. I see people have already added few to the wiki page[1] which is great and all but wikis aren't for discussions.. The plan as I see it: Discuss ideas. Draft them up on the wiki. Move them to php.net/ideas when they are solid enough. I don't really see a point to move them there. wiki.php.net/gsoc/2008 is just fine. One can create sub pages to complete a proposal. New bugtracker for all the *.php.net projects (one-tracker-rules-them-all). What's up with Jani's work? Random other ideas (most probably too small): - openid extension I'm not sure it is a good idea to bring the relatively small API into an extension. The slow and complex part is already possible with openssl (Dmitry's patch). - threaded run-tests.php and graphical stats - mirror-test bot rewrite - automatically run relevant tests on new commit (i.e commits to ext/foo triggers test run for ext/foo/tests) - daily/weekly buildfailure mails to internals@ (win/linux/solaris/bsd/mac/..) - doxygen-to-phpdoc/docbook - user-submitted-coverage to gcov Something like what is done with ctest (cmake's test tool) would rock. I can provide links if there is an interest (or see http://cmake.org) - reST to html/docbook parser I somehow have doubts about reST now that we have a wiki. Too much formats will bring more confusions than really helping to write docs, specs or RFC. Cheers, -- Pierre 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 for opcode caches
Hello Dmitry,
please don't apply. The patch looks rather rough and untested (see below).
Also I really disagree to making the engine even more complex and adding
even more different behavior ways. That way we just introduce more errors
as we cannot test the engine in all its modes. We simply do not have the
infrastructure for that. And that means we will add even more bugs.
Further more I am missgin a description what you really do here and why we
need to do that. Ok Opcode caches have issues but so far all attempts to do
somethign about that have been blocked. Now this one apparently has a new
option. But as far as I can tell it simply allows to change the compiler to
an opcode friendly order. If that is all what it does than we should simply
drop all the options and do it anyway without flags.
unnoticed.
marcus
Friday, March 7, 2008, 12:36:58 PM, you wrote:
Index: Zend/zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.308.2.12.2.35.2.9
diff -u -p -d -r1.308.2.12.2.35.2.9 zend.c
--- Zend/zend.c 5 Mar 2008 13:34:12 - 1.308.2.12.2.35.2.9
+++ Zend/zend.c 7 Mar 2008 11:34:14 -
@@ -463,7 +463,7 @@ static void zend_set_default_compile_tim
CG(asp_tags) = asp_tags_default;
CG(short_tags) = short_tags_default;
CG(allow_call_time_pass_reference) = ct_pass_ref_default;
- CG(extended_info) = extended_info_default;
+ CG(compiler_options) = compiler_options_default;
}
/* }}} */
Why rename this variable? It still is an exetended information in the
compiler globals. It's full name would be compiler_globals_extended_info'
versus 'compiler_globals_compiler_options'.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.46
diff -u -p -d -r1.647.2.27.2.41.2.46 zend_compile.c
--- Zend/zend_compile.c 3 Mar 2008 15:07:04 - 1.647.2.27.2.41.2.46
+++ Zend/zend_compile.c 7 Mar 2008 11:34:15 -
[...]
@@ -2588,7 +2577,7 @@ ZEND_API void zend_do_inheritance(zend_c
if (ce-ce_flags ZEND_ACC_IMPLICIT_ABSTRACT_CLASS ce-type ==
ZEND_INTERNAL_CLASS) {
ce-ce_flags |= ZEND_ACC_EXPLICIT_ABSTRACT_CLASS;
- } else {
+ } else if (!(ce-ce_flags ZEND_ACC_IMPLEMENT_INTERFACES)) {
zend_verify_abstract_class(ce TSRMLS_CC);
}
}
@@ -2700,7 +2689,7 @@ ZEND_API zend_class_entry *do_bind_class
}
return NULL;
} else {
- if (!(ce-ce_flags ZEND_ACC_INTERFACE)) {
+ if (!(ce-ce_flags
(ZEND_ACC_INTERFACE|ZEND_ACC_IMPLEMENT_INTERFACES))) {
zend_verify_abstract_class(ce TSRMLS_CC);
}
return ce;
This looks like a change of behavior to the untrained eye.
[...]
@@ -3238,54 +3235,36 @@ void zend_do_end_class_declaration(znode
ce-line_end = zend_get_compiled_lineno(TSRMLS_C);
- if (!(ce-ce_flags
(ZEND_ACC_INTERFACE|ZEND_ACC_EXPLICIT_ABSTRACT_CLASS))
-((parent_token-op_type != IS_UNUSED) ||
(ce-num_interfaces 0))) {
+ if (!(ce-ce_flags
(ZEND_ACC_INTERFACE|ZEND_ACC_EXPLICIT_ABSTRACT_CLASS))) {
zend_verify_abstract_class(ce TSRMLS_CC);
- if (ce-parent || ce-num_interfaces) {
+ if (ce-ce_flags ZEND_ACC_IMPLEMENT_INTERFACES) {
do_verify_abstract_class(TSRMLS_C);
}
}
- /* Inherit interfaces; reset number to zero, we need it for above
check and
-* will restore it during actual implementation. */
- if (ce-num_interfaces 0) {
- ce-interfaces = NULL;
- ce-num_interfaces = 0;
- }
CG(active_class_entry) = NULL;
}
Again looks like change of behavior.
[...]
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.14
diff -u -p -d -r1.316.2.8.2.12.2.14 zend_compile.h
--- Zend/zend_compile.h 12 Feb 2008 00:20:33 - 1.316.2.8.2.12.2.14
+++ Zend/zend_compile.h 7 Mar 2008 11:34:15 -
@@ -143,6 +143,10 @@ typedef struct _zend_try_catch_element {
/* deprecation flag */
#define ZEND_ACC_DEPRECATED 0x4
+/* class implement interface(s) flag */
'Class implements interface(s) flag' Not the additional s.
Either way, this comment is completely useless. The name of the damn flag
tells me that it has something to do with classes implementing interfaces.
A comment is only uiseful if it adds information. And yes names should be
clear.
+#define ZEND_ACC_IMPLEMENT_INTERFACES 0x8
+
+
char *zend_visibility_string(zend_uint fn_flags);
+
+#define
Re: [PHP-DEV] [GSOC] Ideas?
I do think the wiki page needs some forwarding / segmenting.. etc. Who can/should contribute to it, (how it may not reflect the views of the php group..) Who 'owns' it in the end, and is going to delete proposals they think are a bit off-topic etc... Ideas from any .php net member relating to PHP extensions/core.. Ideas for projects relating to documentation / PHP QA, support infrustructure. PEAR ideas...?? Obviously what get's done really depends on the volunteers, and to some degree finding a project that 'excites' someone... (now there's a real challenge).. Regards Alan Hannes Magnusson wrote: Hi all We should probably discuss some ideas for Google Summer of Code this year. I see people have already added few to the wiki page[1] which is great and all but wikis aren't for discussions.. The plan as I see it: Discuss ideas. Draft them up on the wiki. Move them to php.net/ideas when they are solid enough. Couple of ideas I'd love the see implemented: New bugtracker for all the *.php.net projects (one-tracker-rules-them-all). - Feature requests for specific extensions/module/class/component - Documentation bug for specific extension/module/class/component - Milestones - When a FR is closed then its automatically classified as documentation problem - When a commit contains bug#n the commit message and links to the changed files (diffs) are automatically added to the report - Possibility to reply to reports (add comment, change status) via email - Notification system (i.e. watch this report) which sends email to people watching that report on changes - Monthly reminders to reporters of reports with status feedback/no feedback - No #%#$ signup required to file reports - Possibility to attach files (patch/phpt) - Developer authentication against CVS (fallback to pear/peclweb) accounts - Support for openid (i.e. users with openid don't have to fill out a completely unreadable CAPTCHA) PhD: - PDF format support - CHM format support - man format support - PEAR/Gtk themes - Create a true indexer - Implement the rest of the standard Docbook elements+attributes - Implement default themes for all formats - Support for dbhtml processing instructions Random other ideas (most probably too small): - openid extension - threaded run-tests.php and graphical stats - mirror-test bot rewrite - automatically run relevant tests on new commit (i.e commits to ext/foo triggers test run for ext/foo/tests) - daily/weekly buildfailure mails to internals@ (win/linux/solaris/bsd/mac/..) - doxygen-to-phpdoc/docbook - user-submitted-coverage to gcov - reST to html/docbook parser - translation tool allowing users to suggest better translations ... So, what do you guys think? Have any ideas? -Hannes [1] http://wiki.php.net/gsoc/2008 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Suggestion for get_headers
Hi there, I have a suggestion regarding get_headers, however I do not have a knowledge of C with which to provide a patch. The function get_headers is, as most will know, used to retrieve headers generated by an HTTP request. The primary parameter to this, string $url, is provided unencoded. Due to this, any request with special characters (i.e. a space), will return 400 BAD REQUEST. My suggestion to remedy this, would be to internally apply the function urlencode to the $url parameter. This would automatically encode any provided URL, while remaining transparent. Any comments? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Suggestion for get_headers
Justin Martin wrote: Hi there, I have a suggestion regarding get_headers, however I do not have a knowledge of C with which to provide a patch. The function get_headers is, as most will know, used to retrieve headers generated by an HTTP request. The primary parameter to this, string $url, is provided unencoded. Due to this, any request with special characters (i.e. a space), will return 400 BAD REQUEST. My suggestion to remedy this, would be to internally apply the function urlencode to the $url parameter. This would automatically encode any provided URL, while remaining transparent. Any comments? Thanks, Justin Martin Hi again, Just noticed a discrepancy in my suggestion. I hadn't taken into account that urlencode would encode everything, including parts of the domain name. A solution would have to be used to avoid this. Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [GSOC] Ideas?
HI Alan! On Mon, Mar 10, 2008 at 1:02 AM, Alan Knowles [EMAIL PROTECTED] wrote: I do think the wiki page needs some forwarding / segmenting.. etc. Who can/should contribute to it, (how it may not reflect the views of the php group..) Who 'owns' it in the end, and is going to delete proposals they think are a bit off-topic etc... I believe in self discipline. As long as RFC are in the proposal phase, it can be marked as such, no harm (namespace rfc) Ideas from any .php net member relating to PHP extensions/core.. Ideas for projects relating to documentation / PHP QA, support infrustructure. PEAR ideas...?? I don't think PEAR as a whole has a place there. PEAR has its own wiki and is an independent project. The pear installer itself can certainly be part of GSOC though (keeping the order of the three cases listed by Lukas ealier). Obviously what get's done really depends on the volunteers, and to some degree finding a project that 'excites' someone... (now there's a real challenge).. Yes, that's the challenge. To find someone motivated enough and willing to actually join the project is somehow hard. To find someone who will disappear as soon as the gsoc is over is easier ;) Cheers, -- Pierre 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 for opcode caches
On Mon, Mar 10, 2008 at 5:59 AM, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Dmitry, please don't apply. The patch looks rather rough and untested (see below). Also I really disagree to making the engine even more complex and adding even more different behavior ways. That way we just introduce more errors as we cannot test the engine in all its modes. We simply do not have the infrastructure for that. And that means we will add even more bugs. Further more I am missgin a description what you really do here and why we need to do that. Ok Opcode caches have issues but so far all attempts to do somethign about that have been blocked. Now this one apparently has a new option. But as far as I can tell it simply allows to change the compiler to an opcode friendly order. If that is all what it does than we should simply drop all the options and do it anyway without flags. just a summary of the patch for those who don't have time to read it: ZEND_COMPILE_EXTENDED_INFO is a new way for the extended_info = 1, no logic changed except the api, only a few modules is affected, and yes it can be changed back to avoid breaking 3rd modules at source level the issues relatived to ZEND_COMPILE_DELAYED_BINDING / ZEND_COMPILE_IGNORE_INTERNAL_* can be fixed without those flags. but when we have the flag off the old implementation is used which is more optimized than the new opcode/encoder friendly implementation. correct me if i'm wrong. i'll leave the discussion to you guys, just move it fast before it's too late. thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
On Thu, Mar 6, 2008 at 10:10 AM, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi all, recently there were quite a few proposals about stuff for 5.3. If we implement them all we won't finish in a soonish time and we get new ideas postponing the 5.3 release therefore the following: One thing that never really was resolved were the patches I submitted as a compromise to some of the early disagreements about late static binding. http://marc.info/?l=php-internalsm=119605755711936w=2 There was a little bit of discussion but it was quickly overshadowed by talk of brackets, imports, and other things. I don't necessarily think all of the arguments need to be rehashed again as they have been beaten to death, it would just be good to get an actual decision on whether or not one of them (hopefully the parent:: one) can make it in. If so I can update whichever patch.
