Re: [PHP-DEV][DISCUSSION] Multilingual PHP
We (Russians) have got such experience already. The language is 1S where syntax is Cyrillic. This kind of syntax doesn’t like even Russian patriots. чт, 11 апр. 2019 г., 23:16 Benjamin Morel : > The problem with this approach is that while it may become more readable > for the native speaker, it becomes pretty much impossible to read for the > rest of the world. > Having one single syntax for everyone allows all programmers in the world > to share code. I can't imagine a world where I'd find a library based on > Russian PHP on GitHub, that I can't contribute to or even understand (I > probably wouldn't use it). > English has the huge advantage to be quite simple to learn for basic > purposes, and it has a limited alphabet, composed only of ASCII letters. > > I'm not a native English speaker but have never been bothered by keywords > being called IF and THEN, even when reading BASIC books as a child before > taking any English course at school. > > This may be harder for people having a native language with a different > alphabet, though. > > - Ben > > > On Thu, 11 Apr 2019 at 22:32, Michael Morris wrote: > > > Submitted to the floor is a Wired article from 2 days ago I came across > > > > > > > https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-speak-english/ > > > > The manual of PHP is translated into multiple languages - but what are > the > > development hurdles of the language itself being multilingual? > > > > From what I understand of the compiler - maybe not that much. The > language > > requires an opening tag, so we could hook into that like this example for > > Japanese > > > > > > > A PHP opening tag with such a qualifier would change over all function > > names and reserved words. Could these would be set on a per file basis? > > > > The php.ini file could set the default language, the .htaccess file could > > also on per directory. > > > > I'll stop there cause I know there are problems I haven't thought of. And > > I'm not going to argue the syntax I just kicked out from the top of my > head > > is the best either. > > > > But I think it's worth the effort to at least look into the problem. > Wired > > has a point - people learn to code faster when they are working with > their > > own language. One of the stated goals of PHP's design has been > > accessibility so this seems to be appropriate. > > > > I yield the floor to those smarter and wiser than I. > > >
Re: [PHP-DEV] print with newline
You trеw the bait with no luck. If you didn't get the hint. Your request
have extremely low probability of acceptance.
Try something else.
On Sun, Mar 3, 2019, 05:26 Steven Penny wrote:
> On Sun, 03 Mar 2019 03:36:50, Sara Golemon wrote:
> > function println(string $x): void {
> > echo $x, PHP_EOL;
> > }
> >
> > I hereby grant a public domain license to the above code and wish you
> > godspeed bundling it into a composer package to be enjoyed by users of
> > every active version of PHP.
>
> my request was not "how to print a newline with PHP". the request is for
> PHP to
> implement a builtin method that prints a newline *by default*. currently no
> method exists that i know of.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] reasonability of change the mbfl library
Hello, internals. As Rowan Collins suggested i've replaced lookup table with simple macros: #define UTF16_LE_CODE_UNIT_IS_HIGH_SURROGATE (code_unit & 0xFC00 == 0xD800) #define UTF16_BE_CODE_UNIT_IS_HIGH_SURROGATE (code_unit & 0x00FC == 0x00D8) I repeated the benchmarks again. Here is the results: String foobar was repeated 100 times. Result string size is 11.4mb mb_str_split(): string was splitted by 50 into 12 chunks 1 in 0.400670 s mb_str_split_utf16(): string was splitted by 50 into 12 chunks 1 in 0.038947 s I satisfied my research interest. The question is there practical value? Interested in your opinion. php benchmark code: wrote: > On Sun, 10 Feb 2019 at 12:29, Legale Legage > wrote: > > > > > > > https://github.com/php/php-src/pull/3715/commits/d868059626290b7ba773b957045e08c3efb1d603#diff-22d593ced03b2cb94450d9f9990865c8R38 > > > > To do, or not to do: that is the question. > > What do you think? > > Opening separate pull requests for separate changes is good as it > allows them to be discussed separately. That change is bundled with > the mb_str_split() changes, so it's quite hard to see what is > optimisation and what is part of the approved RFC. > > Although memory is cheap, the change appears to increase the static > allocation of memory by 128KB for something that >95% of PHP > programmers will never use, which is not a good idea. > > > show a more than 2 times speed increase. > > Lies, damn lies and statistics. > > If it takes the time to parse a megabyte string from 0.02 to > 0.01, no one cares. > If it takes the time to parse a megabyte string from 2 seconds to 1 > second, wow that's great! > > i.e. Saying a two times speed increase without context doesn't give > people enough information to evaluate it. > > But this would be easier to discuss as a separate PR. > > cheers > Dan >
Re: [PHP-DEV] reasonability of change the mbfl library
Got it. Thanks. On Mon, Feb 11, 2019, 18:00 Dan Ackroyd On Sun, 10 Feb 2019 at 12:29, Legale Legage > wrote: > > > > > > > https://github.com/php/php-src/pull/3715/commits/d868059626290b7ba773b957045e08c3efb1d603#diff-22d593ced03b2cb94450d9f9990865c8R38 > > > > To do, or not to do: that is the question. > > What do you think? > > Opening separate pull requests for separate changes is good as it > allows them to be discussed separately. That change is bundled with > the mb_str_split() changes, so it's quite hard to see what is > optimisation and what is part of the approved RFC. > > Although memory is cheap, the change appears to increase the static > allocation of memory by 128KB for something that >95% of PHP > programmers will never use, which is not a good idea. > > > show a more than 2 times speed increase. > > Lies, damn lies and statistics. > > If it takes the time to parse a megabyte string from 0.02 to > 0.01, no one cares. > If it takes the time to parse a megabyte string from 2 seconds to 1 > second, wow that's great! > > i.e. Saying a two times speed increase without context doesn't give > people enough information to evaluate it. > > But this would be easier to discuss as a separate PR. > > cheers > Dan >
Re: [PHP-DEV] reasonability of change the mbfl library
Good idea, thanks. should be a bit slower than lookup table, but faster then now. On Sun, Feb 10, 2019, 21:02 Rowan Collins On 10/02/2019 12:29, Legale Legage wrote: > > This conception can be used for the utf-16 encoding, but table size > > would be 65536 bytes against 256 byte for the utf-8 table. > > Rather than two 65 kilobyte lookup tables with most entries identical, > would it be reasonable to use a bit mask to check for the range we care > about? > > I may have this slightly wrong, but something like: > > #define UTF16_LE_CODE_UNIT_IS_HIGH_SURROGATE (code_unit & 0xFC00 == 0xD800) > #define UTF16_BE_CODE_UNIT_IS_HIGH_SURROGATE (code_unit & 0x00FC == 0x00D8) > > m = UTF16_LE_CODE_UNIT_IS_HIGH_SURROGATE(*(uint16_t *)p) ? 4 : 2; > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] reasonability of change the mbfl library
Hello, internals!
While I was working on a new function mb_str_split
(https://wiki.php.net/rfc/mb_str_split) for the extension mbstring, I
noticed a place to seriously improve the mbfl library performance for
the utf-16 encoding.
Currently, all variable-length encodings are processed byte-by-byte.
for(int i = 0; i < string_length; ++i){
...
}
utf-8 strings are processed with precounted char length table.
while (i < string_length) {
int m = mbtab[*p];
i += m;
.
}
This conception can be used for the utf-16 encoding, but table size
would be 65536 bytes against 256 byte for the utf-8 table. Moreover
the tables would be 2, one for the utf-16 big endian and 1 for the
utf-16 little endian.
The results of my tests show a more than 2 times speed increase.
The implementation of the proposed concept is here:
https://github.com/php/php-src/pull/3715/commits/d868059626290b7ba773b957045e08c3efb1d603#diff-22d593ced03b2cb94450d9f9990865c8R38
To do, or not to do: that is the question.
What do you think?
Regards,
Ruslan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpenmod/phpdismod
These scripts allow you to enable/disable php shared extensions. On Sat, 2 Feb 2019 at 21:00, Stanislav Malyshev wrote: > Hi! > > >> I want to propose including to the bundle phpenmod/phpdismod scripts. > These > > I'm sorry but what these scripts are? What do they do? > > -- > Stas Malyshev > smalys...@gmail.com >
Re: [PHP-DEV] phpenmod/phpdismod
On Sat, 2 Feb 2019 at 20:57, Peter Kokot wrote: > On Sat, 2 Feb 2019 at 20:24, Legale Legage > wrote: > > > > Hello, internal. > > > > I want to propose including to the bundle phpenmod/phpdismod scripts. > These > > scripts are included to the standard deb/rpm packages. What do you think > > about including them to the bundle? > > > > If the idea is worthwhile, I will make the RFC. > > > > Saluti, Ruslan > > 1. Will it work also on Alpine Linux and MacOS? From what I see, the > title of these two POSIX shell scripts is "phpenmod - a PHP module > manager for Debian" It depends on us. We can make special scripts for MacOS and even Windows :-). > 2. License MIT will cause any issues with bundling them in php-src? > License allows it. Moreover, i think the author (Ondrej Sury) will be pleased if his creation will be included in the bundle. > 3. Do you know where is the source code of these two scripts? When the > upstream script gets updated it would be then useful to copy/paste > changes into php-src. So the main development should be happening > upstream anyway. Meaning away from the PHP. > I don't know what to say on that. > > What these two scripts do is they enable "extensions" on Debian > installation. For example, phpenmod ftp > Some naming conventions name the PHP extensions (bcmath, openssl, > sodium...) also "modules". So, overall, nothing very simple to create > for all operating systems. Each Linux distribution has different > package repositories, locations to shared extension ini files, so that > is in this situation probably good to be left to 3rd party repository > maintainers or the Linux distro packages maintainers themselves. > > Most likely it will not be easy. > Yes CLI tooling arsenal for more systems/devops oriented PHP world are > in need of improvements. There are many that lack handling extensions > (we were just discussing PECL for example in some other thread)... > > Perhaps the presence of such scripts in the bundle will push the unification process on different systems. In any case, you can always make your own way and not use these scripts. > -- > Peter Kokot On Sat, 2 Feb 2019 at 20:57, Peter Kokot wrote: > On Sat, 2 Feb 2019 at 20:24, Legale Legage > wrote: > > > > Hello, internal. > > > > I want to propose including to the bundle phpenmod/phpdismod scripts. > These > > scripts are included to the standard deb/rpm packages. What do you think > > about including them to the bundle? > > > > If the idea is worthwhile, I will make the RFC. > > > > Saluti, Ruslan > > 1. Will it work also on Alpine Linux and MacOS? From what I see, the > title of these two POSIX shell scripts is "phpenmod - a PHP module > manager for Debian" > 2. License MIT will cause any issues with bundling them in php-src? > 3. Do you know where is the source code of these two scripts? When the > upstream script gets updated it would be then useful to copy/paste > changes into php-src. So the main development should be happening > upstream anyway. Meaning away from the PHP. > > What these two scripts do is they enable "extensions" on Debian > installation. For example, phpenmod ftp > Some naming conventions name the PHP extensions (bcmath, openssl, > sodium...) also "modules". So, overall, nothing very simple to create > for all operating systems. Each Linux distribution has different > package repositories, locations to shared extension ini files, so that > is in this situation probably good to be left to 3rd party repository > maintainers or the Linux distro packages maintainers themselves. > > Yes CLI tooling arsenal for more systems/devops oriented PHP world are > in need of improvements. There are many that lack handling extensions > (we were just discussing PECL for example in some other thread)... > > -- > Peter Kokot >
Re: [PHP-DEV] phpenmod/phpdismod
As a man, being a user at 99%. it has always been very important to have such useful things. At the moment bundle is already generating init.d and systemd scripts. So why not phpenmod / phpdismod? I think usability can not be too much. Sincerely, Ruslan On Sat, 2 Feb 2019 at 20:37, Joe Watkins wrote: > Hi Legale, > > In general we leave the packaging of PHP to the packaging experts. So I > doubt if there's much need to include these in php-src, but let's see what > others have to say ? > > Cheers > Joe > > On Sat, 2 Feb 2019 at 20:24, Legale Legage > wrote: > >> Hello, internal. >> >> I want to propose including to the bundle phpenmod/phpdismod scripts. >> These >> scripts are included to the standard deb/rpm packages. What do you think >> about including them to the bundle? >> >> If the idea is worthwhile, I will make the RFC. >> >> Saluti, Ruslan >> >
[PHP-DEV] phpenmod/phpdismod
Hello, internal. I want to propose including to the bundle phpenmod/phpdismod scripts. These scripts are included to the standard deb/rpm packages. What do you think about including them to the bundle? If the idea is worthwhile, I will make the RFC. Saluti, Ruslan
Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
Hello, internals. I am with you recently. But as a person with a fresh look, let me insert my 5 penny coin. About half a year ago, I knew about the C language only that such a language exists. The reason I decided to contribute is curiosity. So I'm probably not as motivated as some of other internals. I want to say that even a small and fairly simple code change, which I proposed to push through the bureaucracy, was difficult. So If RFC process becomes more difficult this "road" will be closed for some sort of random people like me. I hope this doesn't happen. Best regards, Ruslan On Sat, 2 Feb 2019 at 17:24, Nikita Popov wrote: > Hi internals, > > After discussing the topic with a number of current and former > contributors, I feel that the workflow & voting RFC currently under > discussion is moving us in the wrong direction. I will not comment on the > rather questionable proposed changes to voting eligibility, as these are > already extensively discussed in the RFC thread. > > The remainder of the workflow & voting RFC is mostly concerned with > defining stricter rules and more rigid procedures for the RFC process. It > increases the amount of bureaucracy and overhead involved in the RFC > process, making the RFC processes even less suitable for smaller changes > than it already is. > > The proposal I would like to present in the following is not my own idea, > it has been suggested by Anthony Ferrara. Because I found the idea very > compelling, I'm presenting it to the list now. > > --- > > Instead of making the RFC process more complex and rigid, we should > simplify and streamline it. The RFC process is reduced to only two rules: > > 1. All primary RFC votes require a 2/3 majority, while secondary votes > resolving implementation details may use a simple majority. (This is > already proposed in the voting margins RFC, so discussion about this point > should be directed into the corresponding RFC thread.) > > 2. All RFCs must have a voting period of at least 14 days, announced in a > separate [VOTE] thread. > > --- > > That's it. More notable than the rules itself are probably the two main > omissions: > > 1. There is no required discussion period. However, if an RFC vote is > opened without leaving enough time for discussion, then voters can and > should vote the RFC down on the grounds of insufficient discussion. > > The motivation for not having a fixed discussion period (but a longer > minimum voting period) is that RFCs come in many different forms and sizes. > Some RFCs are long and complex (such as the recent typed properties RFC) > and require more time for an adequate discussion. Other RFCs are simple and > of limited scope (such as an extension function addition) and do not > require extensive discussion. > > While a two week discussion period should remain a good guideline for > language-related RFCs, it is up to the RFC author to decide when opening an > RFC vote is appropriate. This will depend both on the scope of the RFC > itself and the activity of the discussion. (It is an unfortunate fact that > many RFCs receive their first meaningful feedback during the voting > period.) > > 2. There is no moratorium period after an RFC vote fails. If you think that > you have made significant progress on an RFC and resolved the issues that > made the previous vote fail, you can give it another shot at any time, > without having to wait out some fixed period. > > A failed vote does not (necessarily) mean that a feature is not wanted. It > is quite common for significant changes to fail on first vote, due to > issues in the initial proposal. A failed vote should not be a > discouragement, but a motivation to address problems expressed during > discussion or voting. > > It should go without saying that if you restart a failed RFC vote without > making substantial changes to the RFC, the result is unlikely to change in > your favor, and that continued misbehavior might be seen as spam. > > --- > > Essentially, this is about making the RFC process more suitable for changes > small and large, and empowering both RFC authors and the voter base to make > decisions that are appropriate for each RFC. > > What do you think? > > Regards, > Nikita >
Re: [PHP-DEV] Simplify license headers
Intellectual rights include: non-property rights (right to authorship, right to author's name, etc.); property rights (exclusive rights or copyright); A very interesting question appears: Who own the copyright for the PHP source code? Is Nikita right when he says that the copyright on PHP belongs to all the co-authors who contributed to the development? Best regards, Ruslan On 28/01/2019, Zeev Suraski wrote: > >> I would like to make two changes to this header: >> >> 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of >> updating this for >> new major versions. I don't think the version information here is >> particularly useful to >> anybody. > > I don't mind that much, but I don't see any issue with keeping it the way it > is either. It does look nicer the way it is now IMHO, and the cost > associated with changing it twice a decade is, well, not very substantial. > >> 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart from >> requiring a >> yearly update, this line is actually complete misinformation, because the >> PHP group >> does *not* hold the copyright for the PHP source code. This would require >> a copyright >> assignment agreement on behalf of all contributors, which we do not >> collect. >> >> We could also just drop the header entirely, I'm just proposing these two >> changes as >> the path of least resistance towards getting the "annoying" parts >> removed. > > I'm no lawyer, but I do believe a case can be made for claiming that a > person putting code into files with the header 'Copyright (c) XYZ', is in > fact implicitly assigning copyright to XYZ. So while it's not as strong as > an explicit copyright assignment, and while it was never tested in court > (and hopefully never will be) - I do see value in keeping it. I certainly > don't see a reason to change it after 20 years where it didn't seem to > bother anybody, unless there's a strong reason to do that, which currently I > don't see. > > Zeev > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mbstring unused internal functions
Hello. Looking through the source code of the mbstring.c file I found a lot of unused internal functions. It seems that this is just a bunch of old junk. Examples: MBSTRING_API size_t php_mb_mbchar_bytes_ex(const char *s, const mbfl_encoding *enc) MBSTRING_API size_t php_mb_mbchar_bytes(const char *s) MBSTRING_API char *php_mb_safe_strrchr(const char *s, unsigned int c, size_t nbytes) MBSTRING_API char *php_mb_safe_strrchr_ex(const char *s, unsigned int c, size_t nbytes, const mbfl_encoding *enc) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: php-src code style
Got it, thanks! On Sat, 19 Jan 2019 at 15:49, Christoph M. Becker wrote: > On 19.01.2019 at 13:46, Legale Legage wrote: > > > Hello, internals. > > I was trying to find code style guide for php-src project on the > > wiki.php.net > > The only thing i found: > > > > http://doc.php.net/tutorial/style.php > > This is about the documentation (aka. PHP manual). > > > Do we have a code style guide in the form of a document? > > See <https://github.com/php/php-src/blob/master/CODING_STANDARDS>. > > -- > Christoph M. Becker >
[PHP-DEV] php-src code style
Hello, internals.
I was trying to find code style guide for php-src project on the
wiki.php.net
The only thing i found:
http://doc.php.net/tutorial/style.php
Do we have a code style guide in the form of a document?
Will it be ok if I use these parameters:
1. Encoding: utf-8 (without BOM)
2. Line separator: \n
3. Line width: 120 chars
4. If something doesn't fit on the line, then break the line and start on
the next one with a single indent relative to the indent of the current
code block.
Example:
function fun(int a, int b, int c,
int d)
5. Сommas, colons, question marks etc remain on the broken line. Example:
c = (a == b) ?
1 :
2;
char a[] = {
1, 2, 3, 4, 5, 6,
7, 8, 9, 10, 11,
};
Re: [PHP-DEV][RFC] mb_str_split
Help me to find memory leak. Travis CI says:
010+ [Sun Jan 13 18:49:49 2019] Script:
'/home/travis/build/php/php-src/ext/mbstring/tests/mb_str_split_jp.php'
011+ /home/travis/build/php/php-src/ext/mbstring/mbstring.c(646) : Freeing
0x7f59d2c02540 (66 bytes),
https://travis-ci.org/php/php-src/jobs/479101356
What to do next?
On Sun, 13 Jan 2019 at 16:29, Legale Legage wrote:
> Hello, internals!
> NikiC wrote very detailed review about my mb_str_split. So i rewrote the
> function completely. While i was working on new implementation i've noticed
> something in the mbfl library functions: mbfl_substr and mbfl_strlen.
>
>
> if (encoding->flag & MBFL_ENCTYPE_SBCS) {
> len = string->len;
> } else if (encoding->flag & (MBFL_ENCTYPE_WCS2BE | MBFL_ENCTYPE_WCS2LE)) {
> len = string->len/2;
> } else if (encoding->flag & (MBFL_ENCTYPE_WCS4BE | MBFL_ENCTYPE_WCS4LE)) {
> len = string->len/4;
> }
>
> There is 2 more 2-bytes width encodings: MBFL_ENCTYPE_MWC2BE (UTF16-BE),
> MBFL_ENCTYPE_MWC2LE (UTF16-LE).
>
> Is this a mistake or not?
>
> Please check:
> https://github.com/php/php-src/blob/30668755b64aa732246d952451f89d1fcfe581f0/ext/mbstring/libmbfl/mbfl/mbfilter.c#L659
>
[PHP-DEV][RFC] mb_str_split
Hello, internals!
NikiC wrote very detailed review about my mb_str_split. So i rewrote the
function completely. While i was working on new implementation i've noticed
something in the mbfl library functions: mbfl_substr and mbfl_strlen.
if (encoding->flag & MBFL_ENCTYPE_SBCS) {
len = string->len;
} else if (encoding->flag & (MBFL_ENCTYPE_WCS2BE | MBFL_ENCTYPE_WCS2LE)) {
len = string->len/2;
} else if (encoding->flag & (MBFL_ENCTYPE_WCS4BE | MBFL_ENCTYPE_WCS4LE)) {
len = string->len/4;
}
There is 2 more 2-bytes width encodings: MBFL_ENCTYPE_MWC2BE (UTF16-BE),
MBFL_ENCTYPE_MWC2LE (UTF16-LE).
Is this a mistake or not?
Please check:
https://github.com/php/php-src/blob/30668755b64aa732246d952451f89d1fcfe581f0/ext/mbstring/libmbfl/mbfl/mbfilter.c#L659
[PHP-DEV] [RFC][VOTE] mb_str_split
Hello, internals. Please vote this RFC: https://wiki.php.net/rfc/mb_str_split The voting period is: 10.01.2019 - 17.01.2019 Yours sincerely Ruslan
[PHP-DEV] Re: [RFC][VOTE] mb_str_split
Moved back to "Under discussion" stage till 01-10-2019. https://wiki.php.net/rfc/mb_str_split On Sun, 6 Jan 2019 at 00:48, Christoph M. Becker wrote: > On 05.01.2019 at 22:03, Legale Legage wrote: > > > Hello, internals. > > All received suggestions and comments have been settled. Please vote. > > http://wiki.php.net/rfc/mb_str_split > > Thanks for your first RFC! :) > > It seems that you have not opened the voting (search for “doodle” in the > RFC-howto[1]) yet, but you are supposed to start voting only after at > least two weeks have passed since you presented an RFC on this mailing > list (also described in the RFC-Howto), which happened on Jan, 2nd. > > I suggest to change the status of the RFC back to discussion for now, > and to (re-)start the vote later. > > [1] <https://wiki.php.net/rfc/howto > > -- > Christoph M. Becker >
[PHP-DEV] Re: [RFC][VOTE] mb_str_split
Fixed URL: https://wiki.php.net/rfc/mb_str_split <http://wiki.php.net/rfc/mb_str_split> On Sat, 5 Jan 2019 at 22:03, Legale Legage wrote: > Hello, internals. > All received suggestions and comments have been settled. Please vote. > http://wiki.php.net/rfc/mb_str_split >
[PHP-DEV] [RFC][VOTE] mb_str_split
Hello, internals. All received suggestions and comments have been settled. Please vote. http://wiki.php.net/rfc/mb_str_split
[PHP-DEV] RFC mb_str_split
Hello, internals. I would like to introduce you RFC mb_str_split ( https://wiki.php.net/rfc/mb_str_split). mb_str_split it's just a multibyte analog of the native str_split. Let's discuss.
[PHP-DEV] Hello everybody
Hello my name is Ruslan, login on wiki.php.net is rumi. I would like to take a part in php development. Please give me write access to create an RFC.
