Re: [PHP-DEV] PROPOSAL: temp stream for post_data
Hi Gustavo, thank you for your review! On 27 August 2013 23:17, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On 27-08-2013 14:08, Michael Wallner wrote: Hi, I prepared a patch to replace sapi_globals' request_info post_data and raw_post_data with a temp stream and remove support for HTTP_RAW_POST_DATA. [1] PROS: * save up to 300% on post_data_len memory (on non-form POSTs) * a local siege (c=512/512, 2.4k form/2.2k json) showed no (negative) performance impact; see attached logs * reusable php://input stream * ... CONS: * no more $HTTP_RAW_POST_DATA, where BC could easily provided with a one-liner: $GLOBALS[HTTP_RAW_POST_DATA]=file_get_contents(php://input); * memory is cheap * ??? I think it's generally a good idea, but I have some concerns: * The whole point of PG(enable_post_data_reading) is to be able to read the input of the fly. If I read your patch correctly, the data is completely gobbled when you open php://input and then the temp file is reminded. This will result in a serious performance degradation on large inputs, as processing can only start after everything has been read. The behavior should be different if PG(enable_post_data_reading) is false. Ok, *I* thought the whole point of enable_post_data_reading is not to swamp your memory :) We can have that behaviour of course, but then the input stream is not reusable. * I don't see SG(request_info).request_body being closed anywhere. Is this relying just on auto-cleanup? I recall that being problematic in debug mode unless you use php_stream_auto_cleanup(). Yes, list destructors take care of that (I wrote that patch in debug mode). * The php://input streams simply forward the calls to SG(request_info).request_body, so if you open two, the per-stream cursor position may not match the position of the wrapped stream (even if it matched, we wouldn't want one stream to affect the position of the other). I True! So my input stream handles concurrency as bad as the current implementation... 8) don't see any easy way out here; all I can think of is is duping the file descriptor for the temporary file in these situations. But then the book keeping for php://input would be more complicated. I think that shouldn't be too hard to fix. But it depends on concern no.1 :) * The cast added php_stream_get_resource_id() seems unnecessary; may hide bugs. If you just want to be able to pass void* values, better to put an inline function there with a php_stream* parameter, that way you would have a compiler warning if you passed anything but a php_stream* or a void* (though this would break taking a pointer). Thanks, that's a left-over, because I had `void *request_body` in the first place. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
Hi, I would like to react on Stat's it's-not-our-problem comment in https://bugs.php.net/bug.php?id=63520 I am very sad to see a core developer take such a passive-aggressive stance against distributions' problems. My wild guess would be that most of the users use the PHP in the pre-packaged form. Thus we really need to work together and not fight against each other even though the set of the problems (and their solutions) each party solves is different. Pierre did a very good job at approaching Debian and helping us with external libgd library, and it helped a lot a both parties. So I just ask you, please reconsider next time when you want to post similar comment and consider the ecosystem around the PHP in your decisions. Ondrej -- Ondřej Surý ond...@sury.org Have you tried Knot DNS – https://www.knot-dns.cz/ – a high-performance authoritative-only DNS server
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = This would mean that people running PHP without an ini would get UTC as the default and people running with an ini based on php.ini-production/php.ini-development would get the warning. Short of completely dropping the warning this is the behavior that would make most sense to me. (As people running without an ini obviously don't care about setting the timezone) Thanks, Nikita
[PHP-DEV] Re: Pull requests report (27/8/2013)
On 2013-08-27, Lior Kaplan lio...@zend.com wrote: --089e01175f31fb193804e4f1a4bf Content-Type: text/plain; charset=UTF-8 Hi, I'm please to say that we keep processing the requests faster and faster, leaving only few not handled in their first week. Thanks for everyone who helped. Again thanks for this. They are helpful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
On Wed, 2013-08-28 at 08:55 +0200, Ondřej Surý wrote: Hi, I would like to react on Stat's it's-not-our-problem comment in https://bugs.php.net/bug.php?id=63520 I see Stas' reply as respond to Jordi (seld on php.net). We can discuss what *we* *will* do, but for arguing about Debian/Ubuntu *current* packaging decisions it is the wrong place. This has to be discussed in those communities. Those topics are related but still separate topics, decided by different groups. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pull requests report (27/8/2013)
On Tue, Aug 27, 2013 at 8:00 PM, Lior Kaplan lio...@zend.com wrote: Hi, I'm please to say that we keep processing the requests faster and faster, leaving only few not handled in their first week. Thanks for everyone who helped. New: #420 https://github.com/php/php-src/pull/420 Always provide retval ptr #421 https://github.com/php/php-src/pull/421 Dedicated syntax for variadic parameters Merged requests: #197 https://github.com/php/php-src/pull/197 fputcsv improvements to allow RFC 4180 compliance #237 https://github.com/php/php-src/pull/237 Fix DateTime, when use it with D/l in format and textual day have dot at the end #322 https://github.com/php/php-src/pull/322 Fix DateInterval-days value #414 https://github.com/php/php-src/pull/414 Fix #65483: quoted-printable encode stream filter incorrectly encoding #415 https://github.com/php/php-src/pull/415 Remove duplicate calls to set filename lineno for the DTRACE_FUNCTION_ENTRY/RETURN cases #417 https://github.com/php/php-src/pull/417 Stricter libc-client symlink check #419 https://github.com/php/php-src/pull/419 Test extension xmlrpc encode type double and string decode type string and int Closed requests (without merge): #418 https://github.com/php/php-src/pull/418 Add test for #65499 (not a PHP bug) Still open (21 days): #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity Kaplan On Thu, Aug 22, 2013 at 2:24 AM, Lior Kaplan lio...@zend.com wrote: (reporting about two weeks) Merged requests (past 7 days): #359 https://github.com/php/php-src/issues/359 PHPTests for the DOMDocument::load and DOMDocument::loadXML #360 https://github.com/php/php-src/pull/360 Bug44168 #381 https://github.com/php/php-src/issues/381 Fixed #65225: PHP_BINARY incorrectly set #395 https://github.com/php/php-src/issues/395 typofixes - code related #402 https://github.com/php/php-src/issues/402 make the bison version check a blacklist #403 https://github.com/php/php-src/issues/403 Fix #61345: fix install of CGI binary #404 https://github.com/php/php-src/issues/404 php.ini-development/production: remove php_zip.dll #405 https://github.com/php/php-src/issues/405 Fixbug: phpize --clean will delete include/*.h #410 https://github.com/php/php-src/pull/410 Fix for php bug #64802 #411 https://github.com/php/php-src/issues/411 Use pkg-config to detect iodbc #412 https://github.com/php/php-src/issues/412 Create test to the extension xmlrpc, encode array and int. Closed requests (without merge): #325 https://github.com/php/php-src/issues/325 Add schema default/fixed value support in DOM (merged in April, closed now). #329 https://github.com/php/php-src/issues/329 Allow major versions of bison (done as part of #402). New: #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #414 https://github.com/php/php-src/pull/414 Fix #65483: quoted-printable encode stream filter incorrectly encoding #415 https://github.com/php/php-src/pull/415 Remove duplicate calls to set filename lineno for the DTRACE_FUNCTION_ENTRY/RETURN cases #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity Kaplan Thank you very much for helping with this stuff. Julien Pauli
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I agree. 2013/8/28 Nikita Popov nikita@gmail.com On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = This would mean that people running PHP without an ini would get UTC as the default and people running with an ini based on php.ini-production/php.ini-development would get the warning. Short of completely dropping the warning this is the behavior that would make most sense to me. (As people running without an ini obviously don't care about setting the timezone) Thanks, Nikita -- *** Marcel Araujo Analista de Sistemas Desenvolvedor PHP/Zend/JavaScript/jQuery/NodeJS Linux User #490101 http://www.twitter.com/marcelarauj0 http://blog.marcelaraujo.me http://br.linkedin.com/in/marcelaraujo *
Re: [PHP-DEV] Authenticated Encryption in PHP
Jan Ehrhardt in php.internals (Sun, 25 Aug 2013 00:18:10 +0200): I will add the extension to my list of extensions, so any future build will have it as well (after a git pull). See my builds at http://www.apachelounge.com/viewforum.php?f=6 Added this to all my builds, including PHP 5.3 (based on the Aug 20 snapshot): http://www.apachelounge.com/viewtopic.php?t=5537 Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I like the idea of defaulting to UTC. Inevitably, this is how I set up my apps anyway. Bryan -Original Message- From: Marcel Araujo [mailto:ceceld...@gmail.com] Sent: Wednesday, August 28, 2013 7:49 AM To: Nikita Popov Cc: Daniel Lowrey; Derick Rethans; PHP internals Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale? I agree. 2013/8/28 Nikita Popov nikita@gmail.com On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = This would mean that people running PHP without an ini would get UTC as the default and people running with an ini based on php.ini-production/php.ini-development would get the warning. Short of completely dropping the warning this is the behavior that would make most sense to me. (As people running without an ini obviously don't care about setting the timezone) Thanks, Nikita -- *** Marcel Araujo Analista de Sistemas Desenvolvedor PHP/Zend/JavaScript/jQuery/NodeJS Linux User #490101 http://www.twitter.com/marcelarauj0 http://blog.marcelaraujo.me http://br.linkedin.com/in/marcelaraujo * -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Syntax for variadic functions
Hi internals!
I'd like to propose an RFC, which adds dedicated syntax for variadic
functions:
https://wiki.php.net/rfc/variadics
Basically this allows declaring variadics directly in the function
signature, rather than fetching the arguments using func_get_args().
Example:
public function query($query, ...$params) { /* ... */ }
What are your thoughts on this?
Thanks,
Nikita
Re: [PHP-DEV] [RFC] Syntax for variadic functions
2013/8/28 Nikita Popov nikita@gmail.com
Hi internals!
I'd like to propose an RFC, which adds dedicated syntax for variadic
functions:
https://wiki.php.net/rfc/variadics
Basically this allows declaring variadics directly in the function
signature, rather than fetching the arguments using func_get_args().
Example:
public function query($query, ...$params) { /* ... */ }
What are your thoughts on this?
+1, primarily because it makes the code self-documented.
However, I would like to hilight one shortcoming of variadic functions
(both with the old and with the proposed syntax): There is no way to call a
variadic function unless all the arguments are hard-coded.
I am extenting the example of the RFC:
class MySQL implements DB {
public function query($query, ...$params) {
// ...
}
public function query_and_log($query, ...$params) {
// this will not work:
$result = $this-query( $query, $params );
log( $query );
return $result;
}
}
Not only this does not work, but there is no way to make it work without
modifying the original function. Would it be possible to extend the RFC
with new syntax that could cover cases like that as well? Maybe something
like that:
$result = $this-query( $query, ...$params );
Other than that, the RFC is very welcome.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Thanks,
Nikita
Re: [PHP-DEV] [RFC] Syntax for variadic functions
On Wed, Aug 28, 2013 at 6:18 PM, Lazare Inepologlou linep...@gmail.comwrote: Not only this does not work, but there is no way to make it work without modifying the original function. Would it be possible to extend the RFC with new syntax that could cover cases like that as well? Maybe something like that: $result = $this-query( $query, ...$params ); I will implement this, but in a separate RFC :) [Later today or tomorrow] Nikita
Re: [PHP-DEV] [RFC] Syntax for variadic functions
On 28/08/13 17:47, Nikita Popov wrote:
Hi internals!
Hi Nikita :-),
I'd like to propose an RFC, which adds dedicated syntax for variadic
functions:
https://wiki.php.net/rfc/variadics
Basically this allows declaring variadics directly in the function
signature, rather than fetching the arguments using func_get_args().
Example:
public function query($query, ...$params) { /* ... */ }
What are your thoughts on this?
Huge +1!
So if we call query('foo'), $params is set to an empty array, right?
Could it be possible to change this behavior? Would it be interesting?
For example: public function query($query, ...$params = null).
Cheers.
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
Hi! I would like to react on Stat's it's-not-our-problem comment in https://bugs.php.net/bug.php?id=63520 I assume by Stat you mean myself, though I'm not the only one who expressed the same sentiment of questioning why this is submitted as a bug in PHP. Assuming that, below are my thoughts on the subject (I apologize in advance for the length). I am very sad to see a core developer take such a passive-aggressive stance against distributions' problems. My wild guess would be that most of the users use the PHP in the pre-packaged form. Thus we really need to work together and not fight against each other even though the set of the problems (and their solutions) each party solves is different. I assure you that by raising this question I meant no aggression or animosity toward anybody, but I do have a question of priorities here. I understand that Debian has certain ideological guidelines which preclude them from distributing certain software that does not fit their views on how software should be licensed. Even though as far as I know Debian has non-free area in which they distribute software with licenses other than approved by Debian's guidelines, but ultimately I recognize that the decision of what to distribute and what not is Debian's and their alone. However, what happens in PHP project is decided by PHP developers community and should gain consensus and acceptance in the community. However, given all that, I think the matter would be handled better if, before taking decisions that can influence many users of PHP that chose to trust Debian to deliver their PHP builds, Debian would consult with PHP community on how to handle that. I do not remember this question being raised on PHP list and discussed there. I personally found about this decision by reading panic posts in the blogs along the line of PHP removes JSON support, which I do not think is the best outcome we could hope for. I think PHP bug database is neither appropriate nor suitable forum for discussing such things - it is meant for tracking bugs in PHP code, e.g. mistakes made while implementing certain functionalities, and the license of JSON code, which obviously being controversial and causing issues for Debian, is definitely not there by any mistake and should not be treated as bug. It should be treated as licensing issue and as such raised on this list and discussed and handled appropriately. I certainly and wholeheartedly agree that we do need to work together with distributions and that it would benefit our users. As a good start, I would ask Debian representatives to work with PHP community within processes accepted by the community, i.e. explain on this list why it is impossible to distribute PHP the way it was distributed before for years, why it is impossible to fit this code withing any non-free framework Debian has, what Debian suggests to do (taking into account this will influence wider PHP users community, many of whom, however regrettable may it be, do not use Debian) and so on, initiating the discussion that hopefully would come to some conclusion that would be satisfactory to everyone involved. Thanks, -- 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] [RFC] Syntax for variadic functions
On Wed, Aug 28, 2013 at 10:47 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I'd like to propose an RFC, which adds dedicated syntax for variadic functions: ... What are your thoughts on this? I think it's great way to clean things up and add some subtle new functionality, particularly with Lazare's follow-up proposal about expanding an indexed array into arguments. Would any functions get deprecated as a result of this? e.g., func_get_args() I assume it's a syntax error to do function fn(...$foo, $bar) or function fn(...$foo, ...$bar) I assume that function fn($a, $b = null, ...$c) is possible, and the only way to populate $c is to call fn with three or more parameters. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
On Wed, Aug 28, 2013 at 9:50 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I would like to react on Stat's it's-not-our-problem comment in https://bugs.php.net/bug.php?id=63520 However, given all that, I think the matter would be handled better if, before taking decisions that can influence many users of PHP that chose to trust Debian to deliver their PHP builds, Debian would consult with PHP community on how to handle that. I do not remember this question being raised on PHP list and discussed there. http://marc.info/?l=php-internalsm=136768085009866w=2 Kaplan
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
Hi! http://marc.info/?l=php-internalsm=136768085009866w=2 This is great but this is not exactly what I'm talking about. There's a big difference between having an extension that does JSON in PECL and replacing part of PHP core (and very commonly used part) by something else. It very well may be that Remi's extension is ways better that standard one, and it would be a big step forward for PHP to start using it instead of what we have now. But it should be an explicit decision reached by consensus of PHP community, through RFC process, discussion, vote and so on. Now, as I said, Debian can choose what they distribute, including unilaterally. But we can't both say it's Debian's decision alone and that PHP devs should consider it a PHP issue - if it's a PHP issue, than the decision to replace core extension (and not the decision to create PECL extension, which has much less impact and has the consensus almost always implied - who would object against having a PECL extension that does something useful?) should be explicitly taken by PHP community. So if you think it is a PHP issue - please create an RFC with the arguments to that effect, let's get it discussed and reviewed and have it treated as PHP issues should be treated. -- 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] [RFC] Syntax for variadic functions
Am 28.08.2013 21:27, schrieb Matthew Leverton:
On Wed, Aug 28, 2013 at 10:47 AM, Nikita Popov nikita@gmail.com wrote:
snip
Would any functions get deprecated as a result of this? e.g., func_get_args()
snip
It's not a good idea to deprecate the function
func_get_args/func_num_args() because it is used in user land code to
detect if a function was called with a specific argument like the following:
function ($argByRef = null) {
if (func_num_args() 1) {
// do expensive stuff to set $argByRef
$argByRef = true;
}
return false;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
On Wed, Aug 28, 2013 at 10:45 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! http://marc.info/?l=php-internalsm=136768085009866w=2 This is great but this is not exactly what I'm talking about. There's a big difference between having an extension that does JSON in PECL and replacing part of PHP core (and very commonly used part) by something else. Well, having the new implementation in PECL is a logical step to publish the code and let people test it. His mail offers (my emphasis): 1/ update existing pecl/json extension - on pecl for older PHP 5.3 - 5.5 * - on php-src in master / 5.6 * And while the issue was first reported by Debian, the other distributions share the same concerns. This is why PHP should consider this - because the other parts of the eco-system are already going forward with this. I agree to what you said about a bug not being a discussion. But it was the first try to communicate with the community. Today, I would raise the issue differently, but Remi's mail with the subject of Proposal: new implementation of JSON extension should have been a good start. Kaplan
Re: [PHP-DEV] [RFC] Syntax for variadic functions
On Wed, Aug 28, 2013 at 9:27 PM, Matthew Leverton lever...@gmail.comwrote: Would any functions get deprecated as a result of this? e.g., func_get_args() Nope, func_get_args() etc stay. This is now mentioned in https://wiki.php.net/rfc/variadics#userland. I assume it's a syntax error to do function fn(...$foo, $bar) or function fn(...$foo, ...$bar) Correct. This is now mentioned in https://wiki.php.net/rfc/variadics#syntactic_restrictions. I assume that function fn($a, $b = null, ...$c) is possible, and the only way to populate $c is to call fn with three or more parameters. That's also correct :) Nikita
Re: [PHP-DEV] Authenticated Encryption in PHP
Hi, Added this to all my builds, including PHP 5.3 (based on the Aug 20 snapshot): http://www.apachelounge.com/viewtopic.php?t=5537 That's great! Thanks a lot! I would like to correct myself about using GCM and CCM in PHP. These modes are available for encryption/decryption but there is no way how to get an authentication tag. That's a bit problem as it doesn't make sense to use gcm or ccm if you can't get a tag... On top of it the AAD (Additional Authentication Data) can't be set either... I decided to fix that in php-crypto. I have created an issue about PHP API for this modes: https://github.com/bukka/php-crypto/issues/4 . There are two ideas how the API could be designed. It would be very helpful for me to get any feedback as it could result in more usable API. There also are two other issues in https://github.com/bukka/php-crypto/issues . The first is about API for Algorithm class and the second is about choosing a name for the method that create a digest in one step (currenty Digest::make that is not really explaining...). All issues are just about PHP user interface for this extension (there is nothing about internal C implementation). In addition if anyone knows about any objective crypto library that he used in past and thinks that some ideas could be used in this extension, please let me know. I was looking to Zend\Crypt and also plan to properly look to crypto++. Thanks Jakub
[PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Idea for an RFC for a more powerful (and backward compatible) API of random number generator functions. The following psaudocode is self explained (hopfully) const RAND_ALGO_LIBC const RAND_ALGO_MERSENNE_TWISTER const RAND_ALGO_OPENSSL const RAND_ALGO_GMP ... // changed functions (added optional $algo argument) void srand($seed = null, $algo = rand_algo_default()) int rand($min = 0, $max = getrandmax(), $algo = rand_algo_default()) mixed array_rand(array $input, $num_req = 1, $algo = rand_algo_default()) bool shuffle(array $array, $algo = rand_algo_default()) string str_shuffle(string $str, $algo = rand_algo_default()) // new functions // set/get the default algo int rand_algo_default($algo = null) // get a list of available algos array rand_algo_list() // generate random $length bytes string str_rand($length = 1, $algo = rand_algo_default()) // deprecate functions mt_srand() mt_rand() mt_getrandmax() openssl_random_pseudo_bytes() gmp_random() What do you think? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Syntax for variadic functions
How about having the ellipsis _after_ the variable? That then coincides with phpDocumentor's recommended syntax of $c,... and it keeps any typehint or with the variable name (array $arr... versus array ...$arr) and, honestly, I think that reads more easily. On Wed, Aug 28, 2013 at 1:15 PM, Nikita Popov nikita@gmail.com wrote: On Wed, Aug 28, 2013 at 9:27 PM, Matthew Leverton lever...@gmail.com wrote: Would any functions get deprecated as a result of this? e.g., func_get_args() Nope, func_get_args() etc stay. This is now mentioned in https://wiki.php.net/rfc/variadics#userland. I assume it's a syntax error to do function fn(...$foo, $bar) or function fn(...$foo, ...$bar) Correct. This is now mentioned in https://wiki.php.net/rfc/variadics#syntactic_restrictions. I assume that function fn($a, $b = null, ...$c) is possible, and the only way to populate $c is to call fn with three or more parameters. That's also correct :) Nikita
Re: [PHP-DEV] [RFC] Syntax for variadic functions
On Wed, Aug 28, 2013 at 11:01 PM, Damian Wadley p...@requinix.net wrote: How about having the ellipsis _after_ the variable? That then coincides with phpDocumentor's recommended syntax of $c,... That syntax has it neither before nor after, because there is no parameter name. and it keeps any typehint or with the variable name (array $arr... versus array ...$arr) and, honestly, I think that reads more easily. Please see the https://wiki.php.net/rfc/variadics#choice_of_syntax section of the RFC. Quoting: With ref-modifier ($args...) this does not show well that the individual arguments are references, rather than $args itself. With typehint (array $args...) it also looks like the typehint applies to $args itself rather than all variadic arguments. Thanks, Nikita
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
Hi! And while the issue was first reported by Debian, the other distributions share the same concerns. This is why PHP should consider this - because the other parts of the eco-system are already going forward with this. What we need to consider this extension as a replacement for core JSON is: - explanation of advantages and disadvantages (noting that for most PHP users weird license is not a significant disadvantage of the extension) of the change - RFC - API description - potential BC problems - performance impact -- 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] date.timezone E_WARNING -- Really necessary? What's the rationale?
Hi! * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = I think this is fine but for the distros that ship with empty php.ini it'd still produce a warning. But I think enabling zero-ini to run without warnings (with whatever defaults there are) is a good idea. Maybe still worth having RFC and a vote on it. -- 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] [RFC] Syntax for variadic functions
Hi!
I like the idea, the concept of capturing rest of args is pretty
common. But couldn't we in addition have func_get_args() be able to
receive an int argument that would produce the rest in an easier way
for those that prefer func_ger_args()?
I wonder if this makes harder to implement named argument in the future
- which I think we still need to be looking at - but so far doesn't look
like it presents any additional problem compared to func_get_args().
For prototype checks, this:
public function query($query, ...$params);
public function query($query, $param = null, ...$params);
Should be compatible. Same with:
public function query($query, ...$params);
public function query($query);
functions should be able to ignore some arguments, especially ones that
are optional anyway. I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
I think it should also be explicitly specified what $params is if there
is no arguments - null? false? array()? I'd probably prefer array as it
makes it easy to do something like:
public __construct(...$params) {
foreach($params as $k = $v) { $this-$k = $v; }
}
but in any way it should be specified.
I didn't look at the implementation yet, so I'll add comments on that
later.
--
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] Attitude against distributions... (Was: JSON non-free license)
Stas Malyshev in php.internals (Wed, 28 Aug 2013 14:40:06 -0700): What we need to consider this extension as a replacement for core JSON is: - explanation of advantages and disadvantages (noting that for most PHP users weird license is not a significant disadvantage of the extension) of the change - RFC - API description - potential BC problems - performance impact Some PECL extensions rely on (static?) json: couchdb, couchbase and solr. The maintainers of these extensions will have some work to do, unless the replacement is completely BC. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Syntax for variadic functions
functions should be able to ignore some arguments, especially ones that
are optional anyway.
This is not the current behavior, so why should we change it? See:
1 ?php
2
3 interface TestInterface {
4 function query($params = null);
5 }
6
7 class TestImplementation implements TestInterface {
8 function query() {
9
10 }
11 }
Fatal error: Declaration of TestImplementation::query() must be compatible
with that of TestInterface::query() in
/Users/levijm/Projects/HighlightPHP/tmp.php on line 7
Re: [PHP-DEV] [RFC] Syntax for variadic functions
Hi! functions should be able to ignore some arguments, especially ones that are optional anyway. This is not the current behavior, so why should we change it? See: Because it makes no sense? -- 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] Attitude against distributions... (Was: JSON non-free license)
Le 28/08/2013 23:40, Stas Malyshev a écrit : Hi! And while the issue was first reported by Debian, the other distributions share the same concerns. This is why PHP should consider this - because the other parts of the eco-system are already going forward with this. Yes. This is not a Debian only problem. Most of linux distribution are affected (Fedora, Mandriva, Mageia, OpenSuse, Ubuntu...) AFAIK no one have altered PHP. We only build with --disable-json which is available in the standard build process, and build/ship jsonc separately. There is also a consensus to move on this only for new PHP 5.5 and keep json in PHP 5.3 / 5.4 as this problem was not discovered before. What we need to consider this extension as a replacement for core JSON is: - explanation of advantages and disadvantages (noting that for most PHP users weird license is not a significant disadvantage of the extension) of the change Yes, most PHP users don't care of License. especially those who want to do evil ;) But we are PHP project members. And we ship an OpenSource software which is Licensed under the PHP License, a really free License (per FSF definition). So, of course, we expect users to respect this License. And probably, we'd like them to respect OpenSource, so we need to have an exemplary conduct about those License issues. - RFC - API description - potential BC problems - performance impact Already drafted : https://wiki.php.net/rfc/free-json-parser I was thinking to submit this for discussion later (mostly because I will be AFK first week of september), but as the discussion raised now... Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
Le 29/08/2013 00:36, Jan Ehrhardt a écrit : Stas Malyshev in php.internals (Wed, 28 Aug 2013 14:40:06 -0700): What we need to consider this extension as a replacement for core JSON is: - explanation of advantages and disadvantages (noting that for most PHP users weird license is not a significant disadvantage of the extension) of the change - RFC - API description - potential BC problems - performance impact Some PECL extensions rely on (static?) json: couchdb, couchbase and solr. The maintainers of these extensions will have some work to do, unless the replacement is completely BC. Fedora used to build json extension as shared (like most extension). We never encounter any issue with other extension (except load order, but this is a well known and managed thing) jsonc is really a dropin replacement. - for other extension, same API/ABI - for userland Remi. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I would like to react on Stat's it's-not-our-problem comment in https://bugs.php.net/bug.php?id=63520 I assume by Stat you mean myself, Change your first name! It is incompatible with most autocomplete out there ;-) I am very sad to see a core developer take such a passive-aggressive stance against distributions' problems. My wild guess would be that most of the users use the PHP in the pre-packaged form. Thus we really need to work together and not fight against each other even though the set of the problems (and their solutions) each party solves is different. I assure you that by raising this question I meant no aggression or animosity toward anybody, I support your comment, even if I disagree with his conclusion, I never (or rarely ;) saw aggressive comments from Stas but sometimes expressing opinion in a diplomatic way without hearting everyone feeling is alsmot impossible in technical (or half technical here) topics. but I do have a question of priorities here. I understand that Debian has certain ideological guidelines which preclude It is important to keep in mind that not only Debian is concerned about this problem, other distributions have the same issue with this module, it has been brought to our attention many times in the past, via the bug tracker or on this list. It is also the main reason why Remi began to work on an alternative implementation. While being at it he also added some neat new features. them from distributing certain software that does not fit their views on how software should be licensed. Even though as far as I know Debian has non-free area in which they distribute software with licenses other than approved by Debian's guidelines, but ultimately I recognize that the decision of what to distribute and what not is Debian's and their alone. However, what happens in PHP project is decided by PHP developers community and should gain consensus and acceptance in the community. agreed. However, given all that, I think the matter would be handled better if, before taking decisions that can influence many users of PHP that chose to trust Debian to deliver their PHP builds, Debian would consult with PHP community on how to handle that. I do not remember this question being raised on PHP list and discussed there. I personally found about this decision by reading panic posts in the blogs along the line of PHP removes JSON support, which I do not think is the best outcome we could hope for. I think PHP bug database is neither appropriate nor suitable forum for discussing such things - it is meant for tracking bugs in PHP code, e.g. mistakes made while implementing certain functionalities, and the license of JSON code, which obviously being controversial and causing issues for Debian, is definitely not there by any mistake and should not be treated as bug. It should be treated as licensing issue and as such raised on this list and discussed and handled appropriately. Right, but it is good to track issues, be technical, documentation related or lack or wrong licenses, we had many, but minor, license related bug reports. I certainly and wholeheartedly agree that we do need to work together with distributions and that it would benefit our users. As a good start, I would ask Debian representatives to work with PHP community within processes accepted by the community, i.e. explain on this list why it is impossible to distribute PHP the way it was distributed before for years, why it is impossible to fit this code withing any non-free framework Debian has, what Debian suggests to do (taking into account this will influence wider PHP users community, many of whom, however regrettable may it be, do not use Debian) and so on, initiating the discussion that hopefully would come to some conclusion that would be satisfactory to everyone involved. Remi will propose it via the standard process, that means a RFC draft, discussions, votes, etc. He always wanted to do it this way. Having it this new json extension in pecl is about getting more feedback and catch any possible compatibility issues. After a while, it will be proposed it as a dropin replacement for ext/json. Sadly the FUD about PHP dropping json support, which began on a blog post from a totally uninformed person (he corrected his post since), brought way too much attention to this minor problem. However that's not something we can control, welcome to the internet :). That being said, I am all for a more deeper cooperation between distributions and upstream projects. The more it happens, the less differences we will have between a vanilla release and the packages available in the major distributions. Many issues are understanding issues, like suhoshin patches or other changes with high impacts at the core level. That's what I did by inviting the distributions security guys to our security team, for
Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)
hi Remi! On Thu, Aug 29, 2013 at 7:33 AM, Remi Collet r...@fedoraproject.org wrote: But we are PHP project members. And we ship an OpenSource software which is Licensed under the PHP License, a really free License (per FSF definition). Ah? I always read that the PHP License is not actually Free as per FSF definition, and not compatible with their true free license (GPL). Did that change recently? :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]
Subject: Switch from json extension which have a problematic (non-free) license to jsonc dropin free alternative. RFC: https://wiki.php.net/rfc/free-json-parser Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
