Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

Le 29/08/2013 08:25, Stas Malyshev a écrit : > Also, I see the sizes of the encode results is different from ext/json. > Why is that? Stupid bench... data include some values from microtime()... Fixed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php

Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

Le 29/08/2013 08:25, Stas Malyshev a écrit : > Hi! > >> 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 > >>From what I see in the benchmarks, while encoding is on par with c

Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]

Hi! > 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 >From what I see in the benchmarks, while encoding is on par with current implementation, decoding is more than 2x slower.

Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)

Le 29/08/2013 07:54, Pierre Joye a écrit : > hi Remi! > > On Thu, Aug 29, 2013 at 7:33 AM, Remi Collet 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 r

[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

Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)

hi Remi! On Thu, Aug 29, 2013 at 7:33 AM, Remi Collet 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 d

Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)

On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev 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 ;-) >>

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

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 no

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)45

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

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 c

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

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 war

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 JS

Re: [PHP-DEV] [RFC] Syntax for variadic functions

On Wed, Aug 28, 2013 at 11:01 PM, Damian Wadley 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

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

[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

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 i

Re: [PHP-DEV] [RFC] Syntax for variadic functions

On Wed, Aug 28, 2013 at 9:27 PM, Matthew Leverton 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(...

Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)

On Wed, Aug 28, 2013 at 10:45 PM, Stas Malyshev wrote: > Hi! > > > http://marc.info/?l=php-internals&m=136768085009866&w=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 cor

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 wrote: >> > > Would any functions get deprecated as a result of this? e.g., func_get_args() > > > It's not a good idea to deprecate the function func_get_args/func_num_args() because it is used

Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)

Hi! > http://marc.info/?l=php-internals&m=136768085009866&w=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

Re: [PHP-DEV] Attitude against distributions... (Was: JSON non-free license)

On Wed, Aug 28, 2013 at 9:50 PM, Stas Malyshev 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 > > However, given all that, I think the matter would be handled better if, > before taking decisions that can influence man

Re: [PHP-DEV] [RFC] Syntax for variadic functions

On Wed, Aug 28, 2013 at 10:47 AM, Nikita Popov 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

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 thou

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

Re: [PHP-DEV] [RFC] Syntax for variadic functions

On Wed, Aug 28, 2013 at 6:18 PM, Lazare Inepologlou wrote: > 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: >

Re: [PHP-DEV] [RFC] Syntax for variadic functions

2013/8/28 Nikita Popov > 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

[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 functi

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-D

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 o

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

I agree. 2013/8/28 Nikita Popov > On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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

Re: [PHP-DEV] Pull requests report (27/8/2013)

On Tue, Aug 27, 2013 at 8:00 PM, Lior Kaplan 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 Always provide re

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/Ubunt

[PHP-DEV] Re: Pull requests report (27/8/2013)

On 2013-08-27, Lior Kaplan 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 fo

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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 e