Re: [PHP-DEV] Re: [RFC] Script only include/require

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 ac

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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.

AW: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 function

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: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

Re: [PHP-DEV] Re: [RFC] Script only include/require

Hi Stas, On Mon, Feb 23, 2015 at 5:02 PM, Stanislav Malyshev 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 script_exte

RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

> -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 init

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 ta

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

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 ex

Re: [PHP-DEV] PDO_DBLIB type handling

On 22/02/2015 22:02, Yasuo Ohgaki wrote: Hi Matteo, On Sun, Feb 22, 2015 at 7:45 PM, Matteo Beccati 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 PDO_DBLIB doesn't be

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

On Mon, Feb 23, 2015 at 10:28 AM, Joe Watkins 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 having strict type

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

Hi Jan, On Mon, Feb 23, 2015 at 6:32 PM, Jan Ehrhardt 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 is > >very big

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

On Mon, Feb 23, 2015 at 6:52 PM, Yasuo Ohgaki wrote: > ini_set('.php .phar .module .etc'); ini_set('zend.script_extensions', '.php .phar .module .etc'); to be correct. -- Yasuo Ohgaki yohg...@ohgaki.net

RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

> -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 confide

RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

> -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 Wa

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Feb 21, 2015 9:13 PM, "Anthony Ferrara" 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 advantages,

Re: [PHP-DEV] Type hints ...

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 pote

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Feb 22, 2015 6:07 PM, "Joe Watkins" 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 in the RFC

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> -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 ou

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On Feb 22, 2015 9:25 PM, "Nikita Popov" wrote: > > On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov 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. >> cacth (Exception

RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 par

[PHP-DEV] Coercive Scalar Type Hints RFC - Test PR

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 that

RE: [PHP-DEV] Type hints ...

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 helpf

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

Robert, On Mon, Feb 23, 2015 at 3:27 AM, Robert Stoll 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 accurately wit

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 i

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 fa

AW: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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,

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 t

[PHP-DEV] New SAPI development

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 fin

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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) Ze

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 so

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

Yasuo Ohgaki in php.internals (Mon, 23 Feb 2015 18:53:10 +0900): >On Mon, Feb 23, 2015 at 6:52 PM, Yasuo Ohgaki 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 files and

Re: [PHP-DEV] New SAPI development

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 my

[PHP-DEV] User perspective on STH

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 consideration.

[PHP-DEV] [RFC][VOTE] Improve array to string conversion

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 beh

Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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 >

Re: [PHP-DEV] User perspective on STH

This is first answer that makes sense for community needs. Em 23/02/2015 13:01, "Matthew Weier O'Phinney" 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. > If you fee

Re: [PHP-DEV] User perspective on STH

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 s

Re: [PHP-DEV] User perspective on STH

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 value

AW: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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]

Re: [PHP-DEV] Type hints ...

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

[PHP-DEV] The Game Theory of Scalar Type Hint Voting

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 (my

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

Zeev, On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski 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 RFC is ha

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> -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 wrote: > > >

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Mon, Feb 23, 2015 at 6:08 PM, Zeev Suraski 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

Re: [PHP-DEV] User perspective on STH

On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara wrote: > 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

Re: [PHP-DEV] User perspective on STH

On Mon, Feb 23, 2015 at 6:21 PM, Matthew Weier O'Phinney wrote: > On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara > wrote: > > > > 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

Re: [PHP-DEV] User perspective on STH

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

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> -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 interpreta

[PHP-DEV] [VOTE] Exceptions in the engine

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 vot

Re: [PHP-DEV] User perspective on STH

hi Matthew, On Mon, Feb 23, 2015 at 8:01 AM, Matthew Weier O'Phinney 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 impartial,

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

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 (abstarct

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

On Feb 23, 2015 10:09 AM, "Zeev Suraski" 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 find

[PHP-DEV] Proposal: deprecate undefined passed arguments

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 argumen

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Mon, Feb 23, 2015 at 7:09 PM, Zeev Suraski 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

Re: [PHP-DEV] PDO_DBLIB type handling

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 wrote: > On 22/02/2015 22:02, Yasuo Ohgaki wrote: > >> Hi Matteo, >> >> On Sun, Feb 22, 2015 at

Re: [PHP-DEV] Proposal: deprecate undefined passed arguments

2015-02-23 16:32 GMT-03:00 Marc Bennewitz : > 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 fut

Re: [PHP-DEV] PDO_DBLIB type handling

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

Re: [PHP-DEV] Reclassify E_STRICT notices

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 thrown

Re: [PHP-DEV] Proposal: deprecate undefined passed arguments

Hi Marcio, Am 23.02.2015 um 21:15 schrieb Marcio Almada: 2015-02-23 16:32 GMT-03:00 Marc Bennewitz >: 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 intr

Re: [PHP-DEV] User perspective on STH

Hi Matthew, On 23 February 2015 at 16:01, Matthew Weier O'Phinney 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 verbose: > > $va

RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

On Feb 23, 2015 7:43 AM, "Zeev Suraski" 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 Scal

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> -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 wrote: > You're go

Re: [PHP-DEV] New SAPI development

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 - http://www.phpreferencebook.com/html-version/

Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting

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 wr

[PHP-DEV] Mark some functions with PREFER_REF

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 pointle

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

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 - th

[PHP-DEV] Coercive STH RFC updated

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 se

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

Hi Jan, On Tue, Feb 24, 2015 at 12:51 AM, Jan Ehrhardt 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 wrote: > > > >> ini_set('.php .phar .module .etc'); > > > >ini_set('zend.script_extensions', '.php .phar .module .etc

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

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 p

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On 22 February 2015 23:56:18 GMT, Pierre Joye 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 list then we

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

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 i

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> -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 > wrote:

Re: [PHP-DEV] Proposal: deprecate undefined passed arguments

Hi, 2015-02-23 17:41 GMT-03:00 Marc Bennewitz : > 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 https://github.com/search?

Re: [PHP-DEV] [VOTE] Exceptions in the engine

Hi Nikita, On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov 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 primary vote requir

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

Zeev, On Mon, Feb 23, 2015 at 5:53 PM, Zeev Suraski 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 address

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

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

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 24, 2015 1:12 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Well, I am concerned at this error rate we're seeing that we won't cause >

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Feb 23, 2015 2:48 PM, "Rowan Collins" wrote: > > On 22 February 2015 23:56:18 GMT, Pierre Joye 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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On Mon, Feb 23, 2015 at 2:53 PM, Zeev Suraski 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. > > Secondly,

[PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

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 corres

Re: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

Hi Francois, On Tue, Feb 24, 2015 at 1:17 PM, François Laupretre 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 not simulat

RE: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC - BC breaks

Hi Francois, On Tue, Feb 24, 2015 at 2:01 PM, François Laupretre 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 appears in > PHP

Re: [PHP-DEV] [RFC] [VOTE] Remove the date.timezone warning

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 Hi, After discussing this RFC with other people at AFUP, we would

[PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

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 tea

[PHP-DEV] Re: [RFC] Script only include/require

On Mon, Feb 23, 2015 at 6:55 AM, Yasuo Ohgaki wrote: > Hi Dmitry and Nikita, > > On Mon, Feb 23, 2015 at 6:23 AM, Yasuo Ohgaki wrote: > >> I wrote patch and made adjustment in the RFC >> https://wiki.php.net/rfc/script_only_include >> https://github.com/php/php-src/pull/ >> Where to check fi

Re: [PHP-DEV] Reviving scalar type hints

On Fri, Feb 20, 2015 at 10:48 PM, Robert Stoll 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 neither we

Re: [PHP-DEV] Reclassify E_STRICT notices

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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki wrote: > Hi Nikita, > > On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov wrote: > >> Voting on the engine exceptions RFC, which proposes to convert existing >> fatal and recoverable fatal errors into exceptions, has opened: >> >> https://wiki.php.ne

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

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 th

RE: [PHP-DEV] Coercive Scalar Type Hints RFC

> 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: unde

Re: [PHP-DEV] Proposal: deprecate undefined passed arguments

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 thi

[PHP-DEV] [Discussion] Last chance for case-sensitive engine

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 O(1