Hi!
> JSON_FLOAT_AS_STRING
> decode: all float values will be decoded as string
> - It's often an issue for very large float values with many fractional
> digits that are coming from platforms that support larger float
> representation than double. In that case the conversion is lost and there
> i
Hi!
> That one is rather easy to follow and disallow any kind of bully pushes.
"Easy to follow" != "good to follow". I have no idea what you mean by
"bully pushes".
> Which years are you referring to?
The ones that will pass between feature being contributed (which if
enhancements are banned in
Hi!
>> - Up until the first release candidate of x.y.0, small features can be
> added to both the most recent live branch and the new branch being
> prepared for release (so, right now, 5.6.x and 7.0-pre; next summer,
> 7.0.x and 7.1-pre).
>> - Once a new x.y.0 release is ready, x.y-1.z releases s
Am 31.03.2015 22:45 schrieb "Rowan Collins" :
>
> - Up until the first release candidate of x.y.0, small features can be
added to both the most recent live branch and the new branch being prepared
for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and
7.1-pre).
> - Once a new x.y.0 r
Hi Jakub,
On Mon, Mar 30, 2015 at 5:45 PM, Jakub Zelenka wrote:
> On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki wrote:
>>
>> "int" should be fixed also.
>> http://3v4l.org/95dHM
>>
>>
> We have already fix for this: JSON_BIGINT_AS_STRING (
> http://3v4l.org/vYXUk )
>
Excellent.
>
>
>> So opt
That is a stellar response Dan, Thanks for being so clear. I had a feeling
that this might be the case so we'll have to work around it.
Just for clarity and posterity I provided the simplest test case in the
original email not the actual problem. In Drupal this isn't just one place
though becase,
Hi James,
On 31 March 2015 at 21:51, James Gilliland wrote:
> By design, \EngineException does not extend \Exception so code doesn't
> accidentally catch this special type of exception. ...
>
> I don't know if this is all acceptable and/or by design but it is awkward
> so I wanted to bring it to
Hi Dmitry,
Your approach is definitely a better one, and I have no objection to
it whatsoever.
Sorry, I was too busy to look deeply at each class but I can't see any problems.
Nikita Popov wrote:
> does that mean that the same code using strict_types=1 mode will start
> throwing TypeException in
hi,
ps: please keep the "xyz wrote", makes harder to read your replies without it
On Wed, Apr 1, 2015 at 2:57 AM, Stanislav Malyshev wrote:
> Hi!
>
>> The problem is always a definition question, a very subjective question.
>
> Fortunately, we can discuss it, we're not limited to blindly followi
hi,
On Tue, Mar 31, 2015 at 8:31 PM, Grégory Planchat wrote:
> Hi,
>
> I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
> support in any threads on internals nor the wiki. I'm aware that HTTP is the
> responsibility of the underlying web server, but there are new *importan
Le 31/03/2015 23:45, Larry Garfield a écrit :
On 3/31/15 8:31 AM, Grégory Planchat wrote:
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is
the responsibility of the underlying web server, but th
No objections here either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
So testing out PHP 7 I triggered an \EngineException() in Drupal 8. For
various reasons that don't really matter here Drupal uses
set_exception_handler() to provide its own exception handler. What is
important is that the methods used by that handler type hint \Exception for
their arguments. The im
On 1.04.2015 00:31, Rowan Collins wrote:
On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov wrote:
So, if Zend can be optimized to quickly clean the execution
environment,
and easily switch between them, we can have a giant leap towards
concurrent non-blockable PHP. The idea is simple - the Z
On 3/31/15 8:31 AM, Grégory Planchat wrote:
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is
the responsibility of the underlying web server, but there are new
*important* features to consider.
On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov wrote:
>So, if Zend can be optimized to quickly clean the execution
>environment,
>and easily switch between them, we can have a giant leap towards
>concurrent non-blockable PHP. The idea is simple - the Zend environment
>
>should be some struc
hi Nikita,
I don't care about this a lot. I reworked this patch just because it missed
few details, and then found and fixed mistake in ext/intl.
If you think TypeException is better (I think this makes sense), please
implement it on top and commit.
Thanks. Dmitry.
On Tue, Mar 31, 2015 at 11:07
Sorry for the double reply, but I wanted to pick up on one particular point.
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev
wrote:
>Hi!
>
>> That's not quite how it works; the distro package maintainers
>maintain a
>> sort of forked version of upstream code, combining a well-tested
>> u
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev
wrote:
>> This is a straw man as far as the points I made are concerned. I'm
>> talking about the risk of switching from 5.5 to 5.6, which is pretty
>low.
>
>Switching to 5.6 would be useless since what is being propose it to ban
>any enhanc
On Tue, Mar 31, 2015 at 7:49 PM, Anthony Ferrara
wrote:
> All,
>
> Ever since we introduced password_hash() in 5.5, I've been watching
> its usage as much as possible. I've setup google alerts and such, as
> well as auditing implementations I've found on github to try to
> understand how it's use
On 31.03.2015 18:26, Rowan Collins wrote:
Andrey Hristov wrote on 31/03/2015 16:02:
Currently in MT environment the task of data separation is pushed to
the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that
the data is not stored by using TLS but other mechanism and
cooperative
Hi!
> That's not quite how it works; the distro package maintainers maintain a
> sort of forked version of upstream code, combining a well-tested
> upstream release with a set of patches, many of which will be backported
> fixes from newer releases. So the current package in Ubuntu 14.04 LTS
> [se
On Mon, Mar 30, 2015 at 6:06 PM, Dmitry Stogov wrote:
> Hi Dan,
>
> The updated patch is at https://github.com/php/php-src/pull/1205
>
> The main difference is in ext/intl.
> If you don't see any problems I can commit it.
>
> I didn't think about the classes you missed.
>
> Thanks. Dmitry.
>
I'm
> On 31 Mar 2015, at 21:32, Christoph Becker wrote:
>
> Nicolas Oelgart wrote:
>
>>> On 31 Mar 2015, at 20:49, Anthony Ferrara wrote:
>>>
>>> So I'd like to hear your thoughts about raising E_DEPRECATED when the
>>> salt option is specified in 7.0, with ultimately removing the option
>>> in a
Hi!
> The problem is always a definition question, a very subjective question.
Fortunately, we can discuss it, we're not limited to blindly following
predefined set of rules.
> I do not really buy the "I am stuck with x.y" as one has the same
> problem already. And he has barely a 2 years window
On Tue, Mar 31, 2015 at 8:49 PM, Anthony Ferrara
wrote:
> All,
>
> Ever since we introduced password_hash() in 5.5, I've been watching
> its usage as much as possible. I've setup google alerts and such, as
> well as auditing implementations I've found on github to try to
> understand how it's use
Nicolas Oelgart wrote:
>> On 31 Mar 2015, at 20:49, Anthony Ferrara wrote:
>>
>> So I'd like to hear your thoughts about raising E_DEPRECATED when the
>> salt option is specified in 7.0, with ultimately removing the option
>> in a later version.
>
> +1
>
> I'd even go as far as adding a big red
> On 31 Mar 2015, at 20:49, Anthony Ferrara wrote:
>
> All,
>
> Ever since we introduced password_hash() in 5.5, I've been watching
> its usage as much as possible. I've setup google alerts and such, as
> well as auditing implementations I've found on github to try to
> understand how it's used.
I think deprecating it is a good idea, and looking at the documentation it
does mention that not providing it is the intended option; so it isn't a
complete surprise for it to become deprecated.
On 31 March 2015 at 19:49, Anthony Ferrara wrote:
> All,
>
> Ever since we introduced password_hash()
I'd vote yes on this one, if it were an RFC. Please expedite this
deprecation for 7.0.
Can we also deprecate MCRYPT_RAND? I opened an RFC for that a long time ago
and just remembered it.
All,
Ever since we introduced password_hash() in 5.5, I've been watching
its usage as much as possible. I've setup google alerts and such, as
well as auditing implementations I've found on github to try to
understand how it's used.
One thing has become abundantly clear to me: the salt option is
d
Am 31.03.2015 um 19:09 schrieb Grégory Planchat:
> Possible solutions would be :
> 1. About multiplexing :
> 1.a. integrate php-uv in the core in its current form and let
> developers implement their own protocol layer
> 1.b. transform some project like ReactPHP into an extension (using
> Zephi
Le 31/03/2015 16:40, Daniel Lowrey a écrit :
The issue here is this: the web SAPI is historically the most stable thing
about PHP. Supporting things like message push and multiplexing would
require a fundamental change in what the web SAPI is. You would have to
junk the entire model and create so
Andrey Hristov wrote on 31/03/2015 16:02:
Currently in MT environment the task of data separation is pushed to
the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that
the data is not stored by using TLS but other mechanism and
cooperative multitasking is not something that can't
> this ain't exactly true. Currently in MT environment the task of data
> separation is pushed to the TSRM by using TLS. Now, if TSRM is
> reimplemented in a fashion that the data is not stored by using TLS but
> other mechanism and cooperative multitasking is not something that
> can't be done.
>
Pavel,
> Hello,
>
> I would definitely stick with "weak"; it is common naming used across
> many languages and textbooks.
>
> Also, why is the strongly typed mode named "strict" anyways? If
> anything should change, it should be strict to strong, so PHP doesn't
> look like a special snowflake.
St
Hi,
On 31.03.2015 17:40, Daniel Lowrey wrote:
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat wrote:
Le 31/03/2015 15:56, Daniel Lowrey a écrit :
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and has nothing to
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat wrote:
> Le 31/03/2015 15:56, Daniel Lowrey a écrit :
> > HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
> > exists. The protocol impacts the actual HTTP server and has nothing to do
> > with the SAPI runtime which is sim
Le 31/03/2015 15:56, Daniel Lowrey a écrit :
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and has nothing to do
with the SAPI runtime which is simply handed information about the HTTP
request once the server parses it
On Monday, March 30, 2015, Christoph Becker > wrote:
>
> It appears to me that all of these suggestions may hide the fact that
> the arguments are converted to the hinted types. So perhaps "converting
> type hints" might be a good name.
"Coercive" may be a concise term, without the negative con
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and has nothing to do
with the SAPI runtime which is simply handed information about the HTTP
request once the server parses it. The protocol used to communicate those
detail
On Tuesday, 31 March 2015, Zeev Suraski wrote:
> All,
>
>
>
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for this
> featu
> De : Zeev Suraski [mailto:z...@zend.com]
>
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for this
> feature.
What about
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is
the responsibility of the underlying web server, but there are new
*important* features to consider.
I know the feature list for PHP7 is now f
Stanislav Malyshev wrote on 30/03/2015 23:10:
Hi!
If an organisation has standardised on an old version of PHP, there's a
By "old" you're meaning current stable, I presume.
No, current stable is 5.6.x; people have been talking about backporting
to 5.5.x (which has 2 months of "active suppor
On 30/03/15 15:16, Zeev Suraski wrote:
> Personally I think we should go for ‘dynamic’ when we document it, as this
> is the common way to refer to this behavior (dynamic languages). We could
> also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’,
> although I think we can easily
On Mon, Mar 30, 2015 at 4:16 PM, Zeev Suraski wrote:
> All,
>
>
>
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for this
>
On Tue, Mar 31, 2015 at 3:02 PM, Tony Marston wrote:
> "Nikita Popov" wrote in message
> news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com...
>
>>
>> On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev
>> wrote:
>>
>>> Hi!
>>>
>>> I was never happy about this particular ha
"Nikita Popov" wrote in message
news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com...
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev
wrote:
Hi!
I was never happy about this particular hack but that said, unless we
*know* it is not used widely (and I suspect it is
Hi Dan,
any update? should I commit it?
or do you see any problems?
Thanks. Dmitry.
On Mon, Mar 30, 2015 at 7:06 PM, Dmitry Stogov wrote:
> Hi Dan,
>
> The updated patch is at https://github.com/php/php-src/pull/1205
>
> The main difference is in ext/intl.
> If you don't see any problems I can
50 matches
Mail list logo
