-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 20/03/2016 05:29, Rasmus a écrit :
> We have a bit of a problem with how Linux handles huge pages when
> you run out of them.
Yes, especially on old kernel (2.6.32 on RHEL-6)
For the build in my repository :
- - RHEL-6 : build with --disable-huge
On Mon, Mar 21, 2016 at 4:53 PM, Daniel Beardsley wrote:
> > This approach has the smell of magic quotes which we got rid of for
> > very good reason. XHP is much more explicit in separating markup from
> > data and relies far less (not at all when you do it right) on escape
> > hatches.
>
> Huh
> The similarity is that magic quotes assumed that the input data was going to
> be embedded within an SQL query without escaping, and therefore needed
> escaping. Of course that's an invalid assumption, the input data could be
> re-rendered, processed in some arbitrary way, written to a file, sent
I think having the behaviour of language features depend in an incompatible
way on a global runtime setting is a bad idea because it creates nonlocal
effects and means code cannot be realiably composed. Effectively, every
function and method will have an implicit assumption about whether or not
it
> I think having the behaviour of language features depend in an incompatible
> way on a global runtime setting is a bad idea because it creates nonlocal
> effects and means code cannot be realiably composed.
This is probably the best argument against this RFC. Though how often
that issue would co
Results for project PHP master, build date 2016-03-21 06:28:02+02:00
commit: dab8e58
previous commit:48e3459
revision date: 2016-03-20 18:18:14+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Daniel Beardsley wrote on 21/03/2016 06:35:
You are right. Though not all those problems are serious:
* URI escaping:
Does anyone really use or echo when generating a uri?
* Javascript:
Good point, though I would say it's fairly rare to create javascript
code using a php template with v
Honestly, as it stands this is a pretty terrible idea.
1. It has a huge potential for introducing BC breaks.
- I have some code somewhere which uses output buffering and echo to
write cached copies of html pages to disk. This would break that.
- Writing out html like structures when running as
Hi,
basically I agree to you while I see the issue, but I don't think this
is the solution (it might have been a solution if introduced 20 years
ago, making it "secure by default" and let users opt-out where needed,
but now might lead to a BC hell now)
But a comment here:
On Mon, 2016-03-21 at 1
I would like to register
Grateful
--
Augusto S Batista
Andrea Faulds wrote on 17/03/2016 22:32:
Hi Johannes,
Johannes Schlüter wrote:
On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote:
Eih, only to typed properties. Everything else would be insane ;-)
Sorry for being imprecise.
Ok, quite a lot better, but still weird difference to the langua
On Mon, Mar 21, 2016 at 4:37 PM, Rowan Collins
wrote:
> Andrea Faulds wrote on 17/03/2016 22:32:
>
>> Hi Johannes,
>>
>> Johannes Schlüter wrote:
>>
>>> On Wed, 2016-03-16 at 19:15 +0100, Bob Weinand wrote:
>>>
Eih, only to typed properties. Everything else would be insane ;-)
Sorr
Hi David
On Sun, Mar 20, 2016 at 9:08 PM, David Zuelke wrote:
> On 20.03.2016, at 20:50, Jakub Zelenka wrote:
> >
> > Hi,
> >
> > I just wanted to send a quick update about my recent work on openssl ext
> in
> > case someone else wanted to start something similar so we don't have a
> > wasted e
Hi,
> -Original Message-
> From: David Zuelke [mailto:d...@heroku.com]
> Sent: Monday, March 21, 2016 12:30 AM
> To: Anatol Belski
> Cc: Christoph Becker ; Pierre Joye
> ; PHP internals
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>
>
> > On 20.03.2016, at 22:41, Anatol Belski w
On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski
wrote:
> Hi,
>
> > -Original Message-
> > From: David Zuelke [mailto:d...@heroku.com]
> > Sent: Monday, March 21, 2016 12:30 AM
> > To: Anatol Belski
> > Cc: Christoph Becker ; Pierre Joye
> > ; PHP internals
> > Subject: Re: [PHP-DEV] PCRE
Hi Daniel,
When I write scripts that need to behave the same independently of the
value of mbstring.func_overload then I have to remember to be careful
with the functions it affects. It's a drag. I resent having to write
things like mb_strlen($str, '8bit') to get a byte-count knowing that the
Hello,
I am reaching you in order to obtain feedback on this RFC proposal.
I have been playing with PHP 7 for a project in the company that I am
currently working for. One of the many drawbacks that I saw in PHP was the
there were no types. With type hinting I had confindence again in PHP. With
r
On 21.03.2016, at 19:54, Nikita Popov wrote:
>
> On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski wrote:
>> The issue I have with more increasing the stack is that - while as we see
>> till today
>> the default stack size of 32K is enough in the common case, the max of it
>> will be
>> reserved. S
> My experience in Haskell reminded me of this. To have a structure than
> represents uncertainty, is the best way to take away the responsibility
> from NULL. To express it in no other way. But my experience in Java has
> taught me that Optional of something is not a good way to tackle the
> probl
Hi Levi,
Thanks for replying. I don't think that automagically taking the T out of
the Maybe would be a good idea, mainly because sometimes you don't need
the T, you just want to know the result of it. What I would want in that
PHP automagically executes the method myMethod(Maybe $object) if
somet
Hi,
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Monday, March 21, 2016 7:54 PM
> To: Anatol Belski
> Cc: David Zuelke ; Christoph Becker ;
> Pierre Joye ; PHP internals
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>
> The issue I have with
On 21.03.2016, at 19:41, Anatol Belski wrote:
> I've just pushed a fix for this issue, could you please check? A global
> stack space
> Is used in a thread safe manner. I was first setting max to 256K, then
> decreased it
> To 64K for now. My tests on Linux and Windows show your snippet passing,
>
Hi David,
> -Original Message-
> From: David Zuelke [mailto:d...@heroku.com]
> Sent: Monday, March 21, 2016 10:52 PM
> To: Anatol Belski
> Cc: Christoph Becker ; Pierre Joye
> ; PHP internals
> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>
> On 21.03.2016, at 19:41, Anatol Belski
On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote:
So I want to "return a NULL". I want to express uncertainty, a
nonexistence. But I want to express that I will return something. And I
want to have this NULL checking at interpretation time. I want everything,
and none of the drawbacks. As we
On 21.03.2016, at 23:44, Anatol Belski wrote:
>
> What I'm suggesting to do is using a bit finer comb checking with the real
> life situations. Fe what would be the win for the user, either having to
> enable JIT by hand, or to disable it in a rare case. Currently, as for me,
> the latter seems s
Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit :
> But then I realized the problem. There
> are many times where we need uncertainty. Code is a reflection of reality,
> and as such, it must reflect uncertainty. NULL is a good enough way to
> express nonexistence, albeit a bad one.
On Mon, Mar 21, 2016 at 5:03 PM, Stephen Coakley
wrote:
> On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote:
>>
>> So I want to "return a NULL". I want to express uncertainty, a
>> nonexistence. But I want to express that I will return something. And I
>> want to have this NULL checking at in
>
>
>> I was playing with this idea sometime ago, it gives good performance
> boost for code like `for ($i = 0; $i < 10; $i++) $a->getFoo();` but in
> the end of the day it's a very limited optimization.
> If you abstract away from getters and say you want to optimize more and
> more small func
28 matches
Mail list logo
