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
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
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
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
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
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
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.
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
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:
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
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
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
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
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
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,
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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/
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
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
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
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
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
35 matches
Mail list logo
