On 23/02/15 02:49, François Laupretre wrote:
Hi Lester,
I am not sure I understand well, but the extended type syntax partially
described in https://wiki.php.net/rfc/dbc may correspond to what you
describe. Such extended syntax will be part of 'Design by Contract', meaning
it's
On Feb 21, 2015 9:13 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
First off, thanks for putting forward a proposal. I look forward to a
patch that can be experimented with.
There are a few concerns that I have about the proposal however:
Proponents of Strict STH cite numerous
-Original Message-
From: Pavel Kouřil [mailto:pajou...@gmail.com]
Sent: Monday, February 23, 2015 11:49 AM
To: Joe Watkins
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC)
On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins
Zeev,
You're still doubling the number of CPU ops and adding at least one branch
at
runtime, but not a massive difference.
To be honest, I missed an important part in the semantics of the sample
code, the fact that the result of the division in bar() is sent to function
with an integer
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Monday, February 23, 2015 1:54 PM
To: Joe Watkins
Cc: Etienne Kneuss; Jefferson Gonzalez; PHP internals; Anthony Ferrara;
Zeev
Suraski
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
I think our
Hi,
As I fear this post went unnoticed by many potentially interested, I post it in
a new thread.
For those interested in evaluating the impact of ZPP ruleset modications on
internal and userland code, A pull request is now available :
https://github.com/php/php-src/pull/1110
Please note
Hi Lester,
De : Lester Caine [mailto:les...@lsces.co.uk]
Reworking 15+ years of code to create 'dbc' versions of the existing
annotations is another drain on available time. I can see someone
writing a 'converter' program to populate some parts of this, but I'm
not sure just how helpful
Robert,
[Robert Stoll]
Sure, a was just an example to illustrate the problem. I figured it would
not be necessary to say that the value of $b can be completely unknown by the
static analyser - could come from user input, from a database, from
unserialising code etc. (but probably that is
On Feb 22, 2015 9:25 PM, Nikita Popov nikita@gmail.com wrote:
On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Nikita,
I refactored your implementation:
https://github.com/php/php-src/pull/1095
I introduced a class hierarchy to minimize effect on existing code.
Zeev,
Maybe I'm ignorant of something, but isn't the only way you can begin to
infer the type with real confidence is by having strict typed parameters ?
Not at all. You can definitely infer lots of type information without any
type hints, strict or weak. bench.php wouldn't be 25x faster
On Feb 22, 2015 6:07 PM, Joe Watkins pthre...@pthreads.org wrote:
1. Does weak mode could provide the required rules to implement a JIT
with a sane level of memory and CPU usage?
There is no objective answer to the question while it has the clause with
a sane level of
The assertion
Hello,
I would like to ask someone more skilled with PHP internals, where can I
found some documentation when I want to start to develop new PHP SAPI. For
many years I'm using PHP as FastCGI but standrad FastCGI handler and also
new PHPFPM does not suits my needs.
So how to start? Where can I
Hi,
De : Joe Watkins [mailto:pthre...@pthreads.org]
If you can infer the type with confidence, you can do away with coercion
code altogether.
Maybe I'm ignorant of something, but isn't the only way you can begin to
infer the type with real confidence is by having strict typed parameters
Robert,
On Mon, Feb 23, 2015 at 3:27 AM, Robert Stoll p...@tutteli.ch wrote:
Hey all,
tl;dr
Just one point which JIT/AOT people should consider when dealing with PHP.
PHP is highly dynamic and there are enough use cases which makes it
impossible for a static analyser to infer types
Heya Anthony,
-Ursprüngliche Nachricht-
Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
Gesendet: Montag, 23. Februar 2015 14:53
An: Robert Stoll
Cc: PHP internals
Betreff: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
Robert,
On Mon, Feb 23, 2015 at
Yasuo Ohgaki in php.internals (Mon, 23 Feb 2015 18:53:10 +0900):
On Mon, Feb 23, 2015 at 6:52 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
ini_set('.php .phar .module .etc');
ini_set('zend.script_extensions', '.php .phar .module .etc');
to be correct.
Quote from a Drupal 7 .htaccess:
# Protect
On 02/23/2015 05:05 AM, Zeev Suraski wrote:
-Original Message-
From: Joe Watkins [mailto:pthre...@pthreads.org]
Sent: Monday, February 23, 2015 10:03 AM
To: Jefferson Gonzalez
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC)
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Monday, February 23, 2015 4:14 PM
To: Zeev Suraski
Cc: Joe Watkins; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC)
Zeev,
Maybe I'm ignorant of something, but
Hi,
Starting the vote for https://wiki.php.net/rfc/array-to-string.
Please note that, while the initial RFC proposed both options of either
fully supporting the feature, or disabling it, the voting choices are now :
- either definitely disabling array to string conversion,
- or keep current
Hey Anthony,
-Ursprüngliche Nachricht-
Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
Gesendet: Montag, 23. Februar 2015 15:28
An: Robert Stoll
Cc: PHP internals
Betreff: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
Robert,
[Robert Stoll]
Sure, a
On Mon, Feb 23, 2015 at 6:21 PM, Matthew Weier O'Phinney matt...@zend.com
wrote:
On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
snip
And what about other languages that have exactly this behavior? Such
as Go/Hack/Haskell/etc. Do you see casts everywhere? No.
Zeev,
On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski z...@zend.com wrote:
Benjamin,
There’s a fundamental difference between the two RFCs that goes beyond
whether using a global INI setting and the other per-file setting. The
fundamental difference is that the endgame of the Dual Mode
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Monday, February 23, 2015 6:54 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
Zeev,
On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski z...@zend.com wrote:
On Mon, Feb 23, 2015 at 6:08 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Monday, February 23, 2015 6:54 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
Zeev,
Hello,
I'm writing this as an author and maintainer of a framework and many
libraries.
Caveat, for those who aren't already aware: I work for Zend, and report to
Zeev.
If you feel that will make my points impartial, please feel free to stop
reading, but I do think my points on STH bear some
Matt,
And what about other languages that have exactly this behavior? Such
as Go/Hack/Haskell/etc. Do you see casts everywhere? No. You see them
where it needs to be explicit. Otherwise, people just write using the
correct types.
And it also hand-waves over the fact that the same problem
Peter Hodur wrote on 23/02/2015 14:31:
Hello,
I would like to ask someone more skilled with PHP internals, where can I
found some documentation when I want to start to develop new PHP SAPI. For
many years I'm using PHP as FastCGI but standrad FastCGI handler and also
new PHPFPM does not suits
I'm writing this as an author and maintainer of a framework and many libraries.
Caveat, for those who aren't already aware: I work for Zend, and report to Zeev.
If you feel that will make my points impartial, please feel free to stop
reading, but I do think my points on STH bear some
Hello,
with two competing RFCs (has this ever happend before?) we are in an
interesting spot now, game theoretically. Just letting both RFC authors
open and close the votes will bias the votes just by nature of who starts
first.
My (potentially very wrong) armchair analysis of the timeline is
Zeev,
As this is going in circles, this will be my last post here (it seems
we feel the same in this regards):
Those were our results:
PHPNG-JIT (JIT=on) 0.011 (25 times faster than php-7)
gcc -O2 (4.9.2)0.013
gcc -O0 (4.9.2)0.022
This is first answer that makes sense for community needs.
Em 23/02/2015 13:01, Matthew Weier O'Phinney matt...@zend.com escreveu:
I'm writing this as an author and maintainer of a framework and many
libraries.
Caveat, for those who aren't already aware: I work for Zend, and report to
Zeev.
Matt,
The big problem currently is that the engine behavior around casting can lead
to
data loss quickly. As has been demonstrated elsewhere:
$value = (int) '100 dogs'; // 100 - non-numeric trailing values are
trimmed
$value = (int) 'dog100'; // 0- non-numeric values
On 23/02/15 13:49, François Laupretre wrote:
Hi Lester,
De : Lester Caine [mailto:les...@lsces.co.uk]
Reworking 15+ years of code to create 'dbc' versions of the existing
annotations is another drain on available time. I can see someone
writing a 'converter' program to populate some parts
On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara ircmax...@gmail.com wrote:
snip
And what about other languages that have exactly this behavior? Such
as Go/Hack/Haskell/etc. Do you see casts everywhere? No. You see them
where it needs to be explicit. Otherwise, people just write using the
On Feb 23, 2015 7:43 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Monday, February 23, 2015 4:14 PM
To: Zeev Suraski
Cc: Joe Watkins; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Monday, February 23, 2015 9:35 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
On Mon, Feb 23, 2015 at 7:09 PM, Zeev Suraski z...@zend.com wrote:
You're
Hey.
Here are the references that I will be using when I get to develop on my own
SAPI - that is, if I stop being ill…
- https://github.com/johannes/pconn-sapi
https://github.com/johannes/pconn-sapi
- http://www.phpreferencebook.com/html-version/
http://www.phpreferencebook.com/html-version/
Hi internals!
With regard to my E_STRICT RFC [1] Yasuo and another off-the-record mail
expressed a concern about the Only variables should be passed by
reference strict standards warning.
This notices makes sense in a lot of places, e.g.
array_push(getArray(), 1, 2, 3);
is totally
Hi Matthew,
On 23 February 2015 at 16:01, Matthew Weier O'Phinney matt...@zend.com wrote:
Today, without scalar type hints, we end up writing code that has to first
validate that we have something we can use, and then cast it. This can often
be
done with ext/filter, but it's horribly
I like it! That's what I proposed to Anthony (and Andrea before) before
Zeev presented their alternative, to held a double vote on the strict vs
weak feature. It was not met with much enthusiasm, hope they change their
minds with your proposal!
On Mon, Feb 23, 2015 at 5:43 PM, Benjamin Eberlei
On Feb 23, 2015 10:09 AM, Zeev Suraski z...@zend.com wrote:
I agree if we can avoid an INI setting, but this will surely lead to a
Python 2/3
situation.
I don't think it will. But instead of guessing, we should try the patch
with some real world apps and find out. I think that if we
Hi all,
Because the feature freeze for PHP 7 is near I like to know your
thoughts about one more change in passing arguments. Sure this one would
introduce one more deprecated message / BC break but this one s for
reducing BC break in the future!
Currently a caller can pass undefined
On Mon, Feb 23, 2015 at 7:09 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Monday, February 23, 2015 7:20 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
Just
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Monday, February 23, 2015 7:20 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
Just disabling E_DEPRECATED is hiding bugs now.
It's an extreme interpretation.
Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as this is a language change.
A second
hi Matthew,
On Mon, Feb 23, 2015 at 8:01 AM, Matthew Weier O'Phinney
matt...@zend.com wrote:
I'm writing this as an author and maintainer of a framework and many
libraries.
Caveat, for those who aren't already aware: I work for Zend, and report to
Zeev.
If you feel that will make my points
Hi Dimitry,
Am 19.02.2015 um 16:13 schrieb Dmitry Stogov:
Hi Nikita,
I refactored your implementation: https://github.com/php/php-src/pull/1095
I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.
BaseException
On 23/02/2015 21:12, Adam Baratz wrote:
Makes sense to me. (I'm new at how this community works.) Should I include
a patch with the feature request ticket? Should I be working against master?
I'd say you should start by submitting a bug report (if there isn't one
already). Then a pull request
Nikita Popov wrote on 22/02/2015 22:30:
Hi internals!
I would like to propose reclassifying our few existing E_STRICT notices and
removing this error category:
https://wiki.php.net/rfc/reclassify_e_strict
As we don't really have good guidelines on when which type of error should
be
Makes sense to me. (I'm new at how this community works.) Should I include
a patch with the feature request ticket? Should I be working against master?
On Mon, Feb 23, 2015 at 4:42 AM, Matteo Beccati p...@beccati.com wrote:
On 22/02/2015 22:02, Yasuo Ohgaki wrote:
Hi Matteo,
On Sun, Feb 22,
2015-02-23 16:32 GMT-03:00 Marc Bennewitz dev@mabe.berlin:
Hi all,
Because the feature freeze for PHP 7 is near I like to know your thoughts
about one more change in passing arguments. Sure this one would introduce
one more deprecated message / BC break but this one s for reducing BC break
Hi Marcio,
Am 23.02.2015 um 21:15 schrieb Marcio Almada:
2015-02-23 16:32 GMT-03:00 Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin:
Hi all,
Because the feature freeze for PHP 7 is near I like to know your
thoughts about one more change in passing arguments. Sure this one
On 23/02/15 18:09, Zeev Suraski wrote:
I don't think it will. But instead of guessing, we should try the patch
with some real world apps and find out. I think that if we find out we can
migrate Drupal (or whatever) in a couple of days or even a couple of weeks
to be E_DEPRECATED free - this
v0.24 now focuses on one migration strategy – E_DEPRECATED for PHP 7.x, and
E_RECOVERABLE_ERROR (or likely exceptions) for PHP 8.x and later.
wiki.php.net/rfc/coercive_sth
We’ll update the implementation accordingly, and hopefully be able to start
testing to see how bad of a breakage we’re
On 22 February 2015 23:56:18 GMT, Pierre Joye pierre@gmail.com wrote:
Can you all of you stop this madness with moving discussions off list?
It is detestable, against almost all openness and principles behind an
oss
project like php. If we can't discuss anymore design, plans, ideas etc
on
the
Anthony,
Thanks for testing, but it's a bit premature to jump to conclusions.
First, disabling phar is in the patch instructions at
github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be
fixed. We'll address it.
Secondly, as was obvious both from Francois' email and mine, this
-Original Message-
From: Rowan Collins [mailto:rowan.coll...@gmail.com]
Sent: Tuesday, February 24, 2015 12:48 AM
To: Pierre Joye; Anthony Ferrara
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
On 22 February 2015 23:56:18 GMT, Pierre Joye
Hi Nikita,
On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The
Hi,
2015-02-23 17:41 GMT-03:00 Marc Bennewitz dev@mabe.berlin:
Hi Marcio
Wow, nice to see this - didn't noted it before.
But I have to questions/notes:
1. Why you throw only a warning and not an error (deprecating this feature
first). I don't see the benefit.
Because
Hi Jan,
On Tue, Feb 24, 2015 at 12:51 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Yasuo Ohgaki in php.internals (Mon, 23 Feb 2015 18:53:10 +0900):
On Mon, Feb 23, 2015 at 6:52 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
ini_set('.php .phar .module .etc');
ini_set('zend.script_extensions',
Zeev,
Secondly, for some reason you appear very opinionated that this will result
in huge breakage, even though we don't yet have any evidence to suggest it'd
be the case, at least not yet.
So I tried to compile the patch to get a real-world idea of the breaks.
The first thing, PHP's own
Hi!
I noticed very strange behavior under ZTS build with this patch.
It turned out that compiler_globals is not accessible under ZTS build
according to gdb.
Is this intended? If so, where should I put script_extensions char array?
That doesn't look right. If compiler_globals weren't
Zeev,
I missed the initial replies to this, just had a quick read through (of
the kind you have first thing on a Monday morning).
Essentially the problem is this:
My point is that we can do the very same optimizations with coercive
types as well - basically, that there is no delta.
Zeev,
If you can infer the type with confidence, you can do away with coercion
code altogether.
Maybe I'm ignorant of something, but isn't the only way you can begin to
infer the type with real confidence is by having strict typed parameters ?
This sounds like the kind of strict mode we're
Hey all,
tl;dr
Just one point which JIT/AOT people should consider when dealing with PHP. PHP
is highly dynamic and there are enough use cases which makes it impossible for
a static analyser to infer types accurately without using a top type like mixed.
How would you deal with variable
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Monday, February 23, 2015 4:38 AM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC)
Well, yes and no.
In this simple example, you could
Hi Stas,
On Mon, Feb 23, 2015 at 5:02 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
I noticed very strange behavior under ZTS build with this patch.
It turned out that compiler_globals is not accessible under ZTS build
according to gdb.
Is this intended? If so, where should I put
-Original Message-
From: Joe Watkins [mailto:pthre...@pthreads.org]
Sent: Monday, February 23, 2015 10:03 AM
To: Jefferson Gonzalez
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC)
Zeev,
I missed the initial
Stanislav Malyshev in php.internals (Sun, 22 Feb 2015 14:00:02 -0800):
2. Default configuration would break tons of PHP scripts with extensions
other than .php (very frequent case). The BC break potential of this is
very big as it modifies core functionality.
Exactly my point with the Drupal
On 22/02/2015 22:02, Yasuo Ohgaki wrote:
Hi Matteo,
On Sun, Feb 22, 2015 at 7:45 PM, Matteo Beccati p...@beccati.com wrote:
The default behaviour of mysql/pgsql drivers is to convert to the matching
PHP type, if possible. That can be turned off via
PDO::ATTR_STRINGIFY_FETCHES = true.
If
On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins pthre...@pthreads.org wrote:
Zeev,
If you can infer the type with confidence, you can do away with coercion
code altogether.
Maybe I'm ignorant of something, but isn't the only way you can begin to
infer the type with real confidence is by
Hi Jan,
On Mon, Feb 23, 2015 at 6:32 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Stanislav Malyshev in php.internals (Sun, 22 Feb 2015 14:00:02 -0800):
2. Default configuration would break tons of PHP scripts with extensions
other than .php (very frequent case). The BC break potential of this
-Original Message-
From: Joe Watkins [mailto:pthre...@pthreads.org]
Sent: Monday, February 23, 2015 11:29 AM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC)
Zeev,
If you can infer the type with confidence, you
Le 16/02/2015 18:59, Bob Weinand a écrit :
Voting period is 8 days, it will end 24th of February.
The RFC is here:
https://wiki.php.net/rfc/date.timezone_warning_removal
https://wiki.php.net/rfc/date.timezone_warning_removal
Hi,
After discussing this RFC with other people at AFUP, we would
Hi Francois,
On Tue, Feb 24, 2015 at 1:17 PM, François Laupretre franc...@php.net
wrote:
I ran the PHP core 'make test' on a basic configuration, still running a
significant number of 8785 tests.
Note: the restrictions on numeric string conversions (leading
chars/zeroes, trailing chars) are
Hi Francois,
On Tue, Feb 24, 2015 at 2:01 PM, François Laupretre franc...@php.net
wrote:
I don’t understand which E_DEPRECATED you’re talking about. The
E_DEPRECATED mechanism proposed in the RFC is not implemented yet. But,
yes, all these failures will raise E_DEPRECATED, as none of them
On Mon, Feb 23, 2015 at 2:53 PM, Zeev Suraski z...@zend.com wrote:
Thanks for testing, but it's a bit premature to jump to conclusions.
First, disabling phar is in the patch instructions at
github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be
fixed. We'll address it.
The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in
PHP is up for discussion: https://wiki.php.net/rfc/easy_userland_csprng
This proposes adding two methods: `random_bytes()` and `random_int()` that
return cryptographically secure pseudo-random data.
This has been quite a
Hi,
I ran the PHP core 'make test' on a basic configuration, still running a
significant number of 8785 tests.
Note: the restrictions on numeric string conversions (leading chars/zeroes,
trailing chars) are not simulated yet, but they shouldn't change the results
very much.
The ruleset
I don’t understand which E_DEPRECATED you’re talking about. The E_DEPRECATED
mechanism proposed in the RFC is not implemented yet. But, yes, all these
failures will raise E_DEPRECATED, as none of them appears in PHP 5. In such a
case, hiding E_DEPRECATED will remove every failure.
Regards
On Mon, Feb 23, 2015 at 6:55 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Nikita,
On Mon, Feb 23, 2015 at 6:23 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I wrote patch and made adjustment in the RFC
https://wiki.php.net/rfc/script_only_include
On Fri, Feb 20, 2015 at 10:48 PM, Robert Stoll p...@tutteli.ch wrote:
Hi Dmitry and Anthony,
I was skimming through your conversation about JIT/AOT and that type hints
would allow to optimise few things.
I do not know if you are aware of the following but type hints can be
passed by. Hence
De : Anthony Ferrara [mailto:ircmax...@gmail.com]
The first thing, PHP's own phar generator included in the make file
fails due to the new restricted hints (based on the patch provided).
(I had to rebuild with --disable-phar to get it to build).
Let me make that perfectly clear: under
On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Nikita,
On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has
Hi!
So because of the described issues with the existing code base I like to
propose the change to no longer ignore undefined arguments and introduce
E_DEPRECATED messages if a function get's an undefined argument. So the
user get enough time to fix their code before throwing errors in this
Morning!
I want to ask this question one more time before PHP7 feature freeze: can
we the engine case sensitive from PHP=7.0?
There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.
Pros: more simple
Hi!
I would like to propose reclassifying our few existing E_STRICT notices and
removing this error category:
https://wiki.php.net/rfc/reclassify_e_strict
Could you add some more explanation about why it is a good thing? I.e.,
E_STRICT has pretty clear place and hurts no one, why
Hi!
The same applies to private mails about open topics, rfc or patch to try to
get one to change her mind. This is not acceptable and will never be, to my
eyes at least.
I think it's completely OK to discuss whatever matters people like to
discuss anywhere, as long as this does not hurt the
On Feb 23, 2015 2:48 PM, Rowan Collins rowan.coll...@gmail.com wrote:
On 22 February 2015 23:56:18 GMT, Pierre Joye pierre@gmail.com
wrote:
Can you all of you stop this madness with moving discussions off list?
It is detestable, against almost all openness and principles behind an
oss
On 23/02/15 20:57, Zeev Suraski wrote:
They don't upgrade even when there's
no or very little compatibility breakage. That's why 5.3 is still so
popular, and 5.2 isn't rare to find. Let alone 5.4.
You know my position here but not only are the problems of areas that
were deprecated in 5.3
Zeev,
On Mon, Feb 23, 2015 at 5:53 PM, Zeev Suraski z...@zend.com wrote:
Anthony,
Thanks for testing, but it's a bit premature to jump to conclusions.
First, disabling phar is in the patch instructions at
github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be
fixed. We'll
91 matches
Mail list logo
