Hi!
I just updated my notebook to Fedora 21 and am no longer able to
build PHP on it since I now have bison 3.0.2 instead of bison 2.7.
bison 3.0 is blacklisted in Zend/acinclude.m4. Is bison 3.0
incompatible with our parser specification? If so, will it be
upgraded? It's not really a good
Hi!
> First, how is this substantially different from catching an
> exception? With Nikita’s Exceptions in the Engine RFC
> (https://wiki.php.net/rfc/engine_exceptions_for_php7), something like
> this would be possible:
>
> try { return $foo->bar()->qux()->elePHPant()->dance(); } catch
> (EngineE
Hi!
> I think it's confusing the other way, and "instead of raising a fatal
> for calling a method on null, it returns null" is just as simple of
> an explanation.
What is confusing in "no call is made, so nothing is evaluated" or in
"as soon as we see null, we stop and return null"? I can not be
Hi!
> Take a look at the "short circuit" section where I specifically
> address this. It was done to make it easier to reason about in a
> side-effect-ful language like PHP. With this behavior, when you see
>
> $x?->f(g(), h())
I think this is weird magic behavior which should not be part of PHP
> On 11 Dec 2014, at 06:54, Pierre Joye wrote:
>
>> On Thu, Dec 11, 2014 at 5:31 AM, Andrea Faulds wrote:
>>
>> It’s my understanding that ext/mcrypt is quite widely used. Would it not be
>> possible to update the lib to use OpenSSL or something on the backend, so
>> existing applications
On Thu, Dec 11, 2014 at 5:31 AM, Andrea Faulds wrote:
> Hi!
>
>> On 10 Dec 2014, at 06:33, Remi Collet wrote:
>>
>> Having a dead upstream for crypto API is a critical issue :(
>>
>> FYI some downstream (ex RHEL) don't even provide this library.
>> Already too much crypto libraries, and it will b
hi Remi,
On Wed, Dec 10, 2014 at 5:33 PM, Remi Collet wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 05/12/2014 17:17, Scott Arciszewski a écrit :
>> Hi PHP Internals,
>>
>> I've been trying to get in contact with the maintainers of
>> libmcrypt, but every response I've gotten wa
I updated the RFC to include a paragraph on this. The change should be
included as-is and then be part of a potential refactoring, should one
happen.
On Thu, Dec 4, 2014 at 3:26 PM, Ferenc Kovacs wrote:
>
>
> On Thu, Dec 4, 2014 at 1:17 PM, Julien Pauli wrote:
>
>> On Thu, Dec 4, 2014 at 12:39
Hey:
On Wed, Dec 10, 2014 at 11:27 PM, Dmitry Stogov wrote:
> Hi,
>
> Please, review the following patch
> https://gist.github.com/dstogov/fba2cc621ef121826efe
>
> It's huge, but actually, only changes in zend_compile.h are matter. The rest
> is obvious renaming.
>
> the main idea - the smaller t
On Dec 10, 2014, at 4:12 PM, Christoph Becker wrote:
> Josh Watzman wrote:
>
>> However, for a lot of failures, I don't feel that exceptions are
>> appropriate. I tend to only use them for exceptional behavior --
>> usually, some failure that needs to be propagated up a few levels up
>> the sta
Josh Watzman wrote:
> However, for a lot of failures, I don't feel that exceptions are
> appropriate. I tend to only use them for exceptional behavior --
> usually, some failure that needs to be propagated up a few levels up
> the stack, to an appropriate error boundary. This doesn't necessarily
>
On Dec 10, 2014, at 12:30 PM, Robert Stoll wrote:
> I stick with it, evaluating it does not make sense IMO. If I want to execute
> it in any case then I would do something
> like this currently
>
> $g = g();
> $h = h();
> if($x !== null){
> $x->foo($g, $h)->bar(baz());
> }
>
> And with the ?-
>> .huh? I'm not talking about exceptions the object itself throws. In PHP 7,
>> if Nikita's RFC passes, trying to call a method on
>> NULL will throw an exception. That largely negates the need for a special
>> operator, since you can just catch the exception.
>>
>> Thanks.
>> --
>> Andrea Fau
+1
the patch is great.
It doesn't affect non-ZTS build at all.
ZTS build became even a bit faster. :)
And we finally will able to forget about TSRMLS_ macros :)
Non-ZTS ZTS
master native-tls master native-tls bench.php [sec] 1.193 1.195 1.313
1.299 micro_bench.php
[sec] 6.008 6.064 7.470 6.786
> -Ursprüngliche Nachricht-
> Von: Josh Watzman [mailto:jwatz...@fb.com]
> Gesendet: Mittwoch, 10. Dezember 2014 19:43
> An: Robert Stoll
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Nullsafe calls
>
> On Dec 10, 2014, at 8:17 AM, Robert Stoll wrote:
>
> > First of all, I like the
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Mittwoch, 10. Dezember 2014 20:21
> An: Josh Watzman
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Nullsafe calls
>
> Hi again.
>
> > On 10 Dec 2014, at 19:11, Josh Watzman wrote:
> >
> > On Dec 10,
On Wed, Dec 10, 2014 at 11:56 AM, Andrea Faulds wrote:
> I’ve updated the patches for php-src and the specification to implement this,
> along with their tests, and I’ve also updated the RFC.
>
> Now this won’t error:
> "\"\u202e\""
>
> But this still will:
> "\u{foobar"
>
> I think this
> On 10 Dec 2014, at 19:16, Sara Golemon wrote:
>
>> A possible compromise might be to let ‘\u’ through but not ‘\u{‘.
>>
> Still don't like it from the inconsistency with existing escape
> sequence handlers pov, but it'd cover the biggest set of BC issues, so
> I'd be happy with it.
I’ve upda
Hi again.
> On 10 Dec 2014, at 19:11, Josh Watzman wrote:
>
> On Dec 10, 2014, at 9:19 AM, Andrea Faulds wrote:
>
>> First, how is this substantially different from catching an exception? With
>> Nikita’s Exceptions in the Engine RFC, something like this would be possible:
>>
>> try {
>>
On 10 December 2014 at 18:31, Andrea Faulds wrote:
>
> It’s my understanding that ext/mcrypt is quite widely used. Would it not be
> possible to update the lib to use OpenSSL or something on the backend, so
> existing applications would not need changing?
>
Focusing on the "or something". What
Seems good for me. =)
On Wed, Dec 10, 2014 at 10:27 AM, Dmitry Stogov wrote:
> Hi,
>
> Please, review the following patch
> https://gist.github.com/dstogov/fba2cc621ef121826efe
>
> It's huge, but actually, only changes in zend_compile.h are matter. The
> rest is obvious renaming.
>
> the main id
On Wed, Dec 10, 2014 at 10:59 AM, Andrea Faulds wrote:
>> On 10 Dec 2014, at 18:55, Sara Golemon wrote:
>> I was just updating my HHVM patch to match your PHP implementation and
>> an issue came up. The following code, which is valid in PHP5:
>>
>> > echo json_decode("\"ma\u00F1ana\"");
>>
>> Wi
On Dec 10, 2014, at 9:19 AM, Andrea Faulds wrote:
> Hi again,
>
> I was in favour of this, but upon further thought, I’m not sure I am. I
> remember I also initially liked it in Hack and then lost interest.
>
> First, how is this substantially different from catching an exception? With
> Niki
Hi,
hereby the voting on https://wiki.php.net/rfc/native-tls#vote is opened.
The vote starts on 12/10/2014 at 21:00 CET and ends on 12/17/2014 at 21:00
CET.
Regards
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Dec 10, 2014 at 06:59:39PM +, Andrea Faulds wrote:
> A possible compromise might be to let ‘\u’ through but not ‘\u{‘.
+1
I can see that some people might have \u (for what reason I do not know), but it
would be more unlikely for \u{ to be found in 'legacy' code.
--
Alain Williams
> On 10 Dec 2014, at 18:55, Sara Golemon wrote:
>
> On Mon, Dec 8, 2014 at 3:51 PM, Andrea Faulds wrote:
>> Please read through the RFC and cast your vote if you wish to do so:
>>
>> https://wiki.php.net/rfc/unicode_escape
>>
>> Voting starts today (2014-12-08) and ends in 10 days’ time (2014
On Mon, Dec 8, 2014 at 3:51 PM, Andrea Faulds wrote:
> Please read through the RFC and cast your vote if you wish to do so:
>
> https://wiki.php.net/rfc/unicode_escape
>
> Voting starts today (2014-12-08) and ends in 10 days’ time (2014-12-18).
>
I was just updating my HHVM patch to match your PHP
On Dec 10, 2014, at 8:17 AM, Robert Stoll wrote:
> First of all, I like the RFC, I think as well that it is a useful feature for
> PHP and I already have it on my wish list
> ;)
>
> Yet, either I misunderstand the section about short circuiting or I propose
> to change the behaviour.
>
> "If
Hi!
> On 10 Dec 2014, at 06:33, Remi Collet wrote:
>
> Having a dead upstream for crypto API is a critical issue :(
>
> FYI some downstream (ex RHEL) don't even provide this library.
> Already too much crypto libraries, and it will be a mess to provide a
> dead project in an Enterprise distribu
Andrea Faulds wrote on 10/12/2014 17:19:
Finally, this may encourage bad code. As someone helpfully pointed out in the
reddit discussion (http://redd.it/2ot15u), this encourages breaking the Law of
Demeter, i.e. that objects should only talk to their immediate friends.
Usually, long chains of
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 05/12/2014 17:17, Scott Arciszewski a écrit :
> > Hi PHP Internals,
> >
> > I've been trying to get in contact with the maintainers of
> > libmcrypt, but every response I've gotten was, "Oh, I haven't been
> > a part of that for years."
> >
>
Hi,
> On 10 Dec 2014, at 17:21, Rowan Collins wrote:
>
> Andrea Faulds wrote on 10/12/2014 16:04:
>>
>> It looks like those changes aren’t in master. Once this RFC passes, I’d very
>> much like to see a new attempt to make the names consistent, it’s something
>> that’s bothered me. If this wa
> On 9 Dec 2014, at 23:07, Josh Watzman wrote:
>
> Hey internals! A useful feature that Hack picked up in the last few months
> are "nullsafe calls", a way of propagating failure forward in a series of
> chained method calls to the end of the whole computation, getting rid of a
> lot of the b
Andrea Faulds wrote on 10/12/2014 16:04:
On 9 Dec 2014, at 15:27, Rowan Collins wrote:
Andrea Faulds wrote on 09/12/2014 14:10:
On 9 Dec 2014, at 13:23, Rowan Collins wrote:
Note that in master, the messages have been changed to (correctly) not mention the C
types, only the PHP ones, so it
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 10. Dezember 2014 17:20
> An: 'Josh Watzman'; 'PHP internals'
> Betreff: AW: [PHP-DEV] [RFC] Nullsafe calls
>
> > -Ursprüngliche Nachricht-
> > Von: Robert Stoll [mailto:p...@tutteli.ch
> -Ursprüngliche Nachricht-
> Von: Robert Stoll [mailto:p...@tutteli.ch]
> Gesendet: Mittwoch, 10. Dezember 2014 17:17
> An: 'Josh Watzman'; 'PHP internals'
> Betreff: AW: [PHP-DEV] [RFC] Nullsafe calls
>
> Hi,
>
> > -Ursprüngliche Nachricht-
> > Von: Josh Watzman [mailto:jwatz...
Hi,
> -Ursprüngliche Nachricht-
> Von: Josh Watzman [mailto:jwatz...@fb.com]
> Gesendet: Mittwoch, 10. Dezember 2014 00:08
> An: PHP internals
> Betreff: [PHP-DEV] [RFC] Nullsafe calls
>
> Hey internals! A useful feature that Hack picked up in the last few months
> are "nullsafe calls",
> On 9 Dec 2014, at 15:27, Rowan Collins wrote:
>
> Andrea Faulds wrote on 09/12/2014 14:10:
>>> On 9 Dec 2014, at 13:23, Rowan Collins wrote:
>>>
>>> Note that in master, the messages have been changed to (correctly) not
>>> mention the C types, only the PHP ones, so it would be more like "e
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efe
It's huge, but actually, only changes in zend_compile.h are matter. The
rest is obvious renaming.
the main idea - the smaller the zend_op structure, the lees memory traffic
is required to load VM instruct
Hi!
> Why?
>
> There is a reference counter, which should be increased on put a value
> into persistence and on removing a value from persistence decrease it.
> So the GC could handle unreferenced zvals.
Because memory which is allocated by the engine is freed at the end of
the request. You coul
40 matches
Mail list logo
