Re: [PHP-DEV] [RFC] UString

Morning internals, This is just a quick note to announce my intention to ready this RFC for voting next week. I know I'm a little late maybe, I was real sick most of last week, so couldn't do anything useful. A couple of us intend to fix outstanding issues on github and those raised

Re: [PHP-DEV] [VOTE] Expectations

Morning Internals, As mentioned on the RFC, voting finished last night at midnight. The vote passed with a majority (50%+) in favour of custom exceptions, however ... When the patch was originally written assert (expect) was a language construct, and so the exception message wasn't c

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

Am 28.02.2015 um 01:57 schrieb Larry Garfield: > The RFC is currently in voting, so editing it directly is a no-no. A new, > short RFC, please. (Exception implements Throwable, Error implements > Throwable sounds good to me. Should we ask about SomeUserspaceClass > implements Throwable, or will

Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI

Hi! > I have no intention to change current include/require syntax, except adding > 2nd parameter. This is a bit misleading since include is not a function, so there's no 1st parameter. Instead, it's a syntax construct. Of course, syntax construct's grammar can be changed, though I'm not sure if

[PHP-DEV] Re: Zend JIT Open Sourced

Hey: On Fri, Feb 27, 2015 at 8:10 PM, Dmitry Stogov wrote: > Hi, > > With the recent discussions of JIT/AOT and the good progress we made on > PHP-7, we decided to open up the JIT experiment we've been working on. > > https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit > > You may

Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI

Hi all, On Sat, Feb 28, 2015 at 11:37 AM, Yasuo Ohgaki wrote: > On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins > wrote: > >> Yasuo Ohgaki wrote on 27/02/2015 03:44: >> >>> Hi all, >>> >>> This is RFC for removing "allow_url_include" INI option. [1] >>> >>> During "Script only include" RFC[2] di

Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI

Hi Rowan, On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins wrote: > Yasuo Ohgaki wrote on 27/02/2015 03:44: > >> Hi all, >> >> This is RFC for removing "allow_url_include" INI option. [1] >> >> During "Script only include" RFC[2] discussion, stream wrapper issue is >> raised. >> I was thinking thi

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

Sebastian Bergmann wrote: > I am sorry that I was unable to raise this concern earlier (did not > really become aware of the RFC before it was put to the vote), but I > would prefer the following: > >* Introduce a Throwable interface >* Let Exception implement the Throwable interface >

Re: [PHP-DEV] [RFC][VOTE] Scalar Type Declarations v0.5

On 2/26/15 8:58 AM, Anthony Ferrara wrote: All, I have opened voting on Scalar Type Declarations v0.5. Please cast your vote. https://wiki.php.net/rfc/scalar_type_hints_v5#vote The vote will remain open until March 13th, 2015 or until the date a competing RFC closes voting, whichever is later.

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

On 2/27/15 9:28 AM, guilhermebla...@gmail.com wrote: +1 on Sebastian's suggestion. =) I volunteer to either update the RFC or create a new one to resolve this once "Exceptions in the engine" passes (which looks like a reality already to me). Just tell me which approach I should take and I'll ha

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 2/27/15 10:15 AM, Christian Stoller wrote: From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 4:54 PM Hi Christian, On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller wrote: It is not a bug. FALSE as a return value of substr() is the identificator for an error (

Re: [PHP-DEV] aes_decrypt() aes_encrypt() (was Re: crypto_something)

On 2/27/15, 4:29 PM, "Leigh" wrote: >On 27 February 2015 at 21:14, Tom Worster wrote: > >> I don't see why we couldn't sponsor an effort to encourage adoption >> of this or some such interoperability protocol. Go to FIG, see if the >> Rails, Node and Django people are interested, and so fourth..

Re: [PHP-DEV] A different user perspective on scalar type declarations

Hi Francois, On Fri, Feb 27, 2015 at 10:12 PM, François Laupretre wrote: > > If we allow for trailing blanks, we'll allow the same set of chars that is already allowed for leading blanks. > > I say'blanks' and not 'whitespaces', because here is the list currently allowed as leading blank (with as

Re: [PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference

Hi all, the rfc was declined: - Allow $errstr parameter to be passed by reference: 3 - Allow $errno, $errstr, $errfile, $fileno parameter to be passed by reference: 1 - No, Allow none of the parameter be a reference parameter: 16 Regards Thomas Thomas Bley wrote on 13.02.2015 21:51: > Hi all!

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 27/02/15 21:14, Damien Tournoud wrote: > Hi Lester, > > On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine > wrote: > > > Please, read the examples again, the current behavior is nothing but > > inconsistent: > > > > substr("a", 1) => FALSE > > su

Re: [PHP-DEV] [VOTE] Expectations

On Thu, Feb 19, 2015 at 2:09 AM, Joe Watkins wrote: > The expectations RFC is now in voting phase: > https://wiki.php.net/rfc/expectations#vote This announcement doesn't say when voting will close and the RFC doesn't either. When do you expect voting to close? -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Zend JIT Open Sourced

> On Feb 27, 2015, at 11:36 AM, Anthony Ferrara wrote: > > Dmitry, > >>> That's not to say there's anything wrong with this approach, nor that >>> there isn't a ton we can learn from it. I think it's a fantastic >>> research effort and plan on digging through it myself. Thank you for >>> open so

Re: [PHP-DEV] aes_decrypt() aes_encrypt() (was Re: crypto_something)

On 27 February 2015 at 21:14, Tom Worster wrote: > 1. You say it "doesn't leave any room for interoperability" but I'm > not sure I agree. I invite you again to look at the Cryptography lib > for Python. There are countless applications/services that will do things "their own way", and the odds o

RE: [PHP-DEV] Re: Zend JIT Open Sourced

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 27, 2015 10:54 PM > To: Zeev Suraski > Cc: Dmitry Stogov; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > Zeev, > > On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski wrote: >

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Hi Lester, On Fri, Feb 27, 2015 at 9:53 PM, Lester Caine wrote: > > Please, read the examples again, the current behavior is nothing but > > inconsistent: > > > > substr("a", 1) => FALSE > > substr("a", -300) => "" > > ? That was the case prior to PHP5.2.1 > The fixes in 5.2.2 were not commo

[PHP-DEV] aes_decrypt() aes_encrypt() (was Re: crypto_something)

On 2/26/15 11:12 AM, Leigh wrote:> On 26 February 2015 at 15:37, Tom Worster wrote: > I've spoken with Anthony and a couple of others about something in the > same vein as the new csprng functions. I think core needs a pair of > functions that handles the needs of the 99%. Those functions are. >

Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http

The vote on the pecl_http RFC has been closed, thanks to everyone who participated. The results are 9 in favour and 23 against, so the RFC was declined, which is actually an understatement ;) > On 27 02 2015, at 18:19, Pascal MARTIN, AFUP wrote: > > > Le 26/02/2015 12:28, Michael Wallner a

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 11:53 PM, Anthony Ferrara wrote: > Zeev, > > On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski wrote: > >> -Original Message- > >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] > >> Sent: Friday, February 27, 2015 10:21 PM > >> To: Dmitry Stogov > >> Cc: Zeev Sur

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 27/02/15 20:28, Damien Tournoud wrote: > Hi Lester, > > On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine > wrote: > > This may not be what YOU want substr to do and it would perhaps be > useful to ADD additional checks so that 'false' is returned when it >

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Zeev, On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski wrote: >> -Original Message- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Friday, February 27, 2015 10:21 PM >> To: Dmitry Stogov >> Cc: Zeev Suraski; Jordi Boggiano; PHP Internals >> Subject: Re: [PHP-DEV] Re: Zend JIT

RE: [PHP-DEV] Re: Zend JIT Open Sourced

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 27, 2015 9:36 PM > To: Dmitry Stogov > Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > And looking at the code, I can see why. The PHP ve

RE: [PHP-DEV] Re: Zend JIT Open Sourced

> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, February 27, 2015 10:21 PM > To: Dmitry Stogov > Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > Dmitry, > > > Sneaky sneaky. Also completely fake

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Hi Lester, On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine wrote: > This may not be what YOU want substr to do and it would perhaps be > useful to ADD additional checks so that 'false' is returned when it > can't created a string because of the 'invalid arguments', but type > hints makes no differ

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 11:21 PM, Anthony Ferrara wrote: > Dmitry, > > > Sneaky sneaky. Also completely fake. > > It's been brought to my attention that some people have taken what I > said completely out of context and insinuated it as a direct insult to > you. I assure you that was not the inte

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara wrote: > Dmitry, > > >> That's not to say there's anything wrong with this approach, nor that > >> there isn't a ton we can learn from it. I think it's a fantastic > >> research effort and plan on digging through it myself. Thank you for > >> open

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Dmitry, > Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. I assure you that was not the intent (I called the benchmark sneaky and fake, which it is). So if you in

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara wrote: > Dmitry, > > >> That's not to say there's anything wrong with this approach, nor that > >> there isn't a ton we can learn from it. I think it's a fantastic > >> research effort and plan on digging through it myself. Thank you for > >> open

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Dmitry, >> That's not to say there's anything wrong with this approach, nor that >> there isn't a ton we can learn from it. I think it's a fantastic >> research effort and plan on digging through it myself. Thank you for >> open sourcing it. > > > Thanks for good words :) > > This work may be adop

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 9:55 PM, Anthony Ferrara wrote: > Zeev, > > >> Right now it compiles script (php file) at once. > >> So yes, our JIT uses some kind of AOT approach, but completely > >> transparently for the rest of PHP. > > > > Just to slightly further clarify - we don't compile the whole

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Zeev, >> Right now it compiles script (php file) at once. >> So yes, our JIT uses some kind of AOT approach, but completely >> transparently for the rest of PHP. > > Just to slightly further clarify - we don't compile the whole codebase at > once, but we keep the existing semantics that every file

Re: [PHP-DEV] Zend JIT Open Sourced

hi, On Fri, Feb 27, 2015 at 4:10 AM, Dmitry Stogov wrote: > Hi, > > With the recent discussions of JIT/AOT and the good progress we made on > PHP-7, we decided to open up the JIT experiment we've been working on. > > https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit > > You may ju

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 27/02/15 16:46, Damien Tournoud wrote: > You probably haven't read the examples that I pasted. If you think that it > makes sense to return an error code if the function is called with invalid > arguments, it should be done consistently. The current behavior is just an > absurdly inconsistent, i

RE: [PHP-DEV] Re: Zend JIT Open Sourced

> -Original Message- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Friday, February 27, 2015 7:31 PM > To: Anthony Ferrara > Cc: Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara > wrote: > > > Dmi

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

This RFC trying to simpliy and cleanup the coercison rules, having two different conversion rules for NULL->scalar depending on userland or internal is counter-productive and bad. The behavior you describe as null being empty value is wide-spread in PHP userland code as well. I agree here with B

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara wrote: > Dmitry, > > > > It's not a single request cycle. JIT integrated into opcache, it compiles > > php script(s) of first access and stores code in shared memory. > > On following requests precompiled code is executed directly from shared > > m

Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http

Le 26/02/2015 12:28, Michael Wallner a écrit : I forgot to formally declare a voting period, so I’ll do so now. Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do so until then. https://wiki.php.net/rfc/pecl_http#vote Hi, Not many of us at AFUP participated in

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 27/02/15 14:15, Benjamin Eberlei wrote: > Imho the problem is that the return values of php internal functions being > string|false will lead to massive consecutive errors when passing this on > to other internal functions. This is perhaps the crux of my objection to both types of 'error checki

Re: [PHP-DEV][RFC][VOTE] Enable error_handler callback parameters to be passed by reference

Le 13/02/2015 21:51, Thomas Bley a écrit : we'd like to initiate a vote on Allow error_handler callback parameters to be passed by reference: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference Hi, We've discussed this RFC with a few other people at AFUP, and we

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Dmitry, > It's not a single request cycle. JIT integrated into opcache, it compiles > php script(s) of first access and stores code in shared memory. > On following requests precompiled code is executed directly from shared > memory. > > - The first request may be extremely slow (few minutes) Th

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Hi Christian, On Fri, Feb 27, 2015 at 5:15 PM, Christian Stoller wrote: > In this case FALSE is an expected result and it is intended. And as > I said other languages are going the same way. > Other languages are also doing something saner. It's not really an argument either way. Just because

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Dmitry Stogov wrote on 27/02/2015 15:56: On Fri, Feb 27, 2015 at 6:40 PM, Jordi Boggiano wrote: >On 27/02/2015 15:19, Andi Gutmans wrote: > >> >> On Feb 27, 2015, at 7:12 AM, Anthony Ferrara >>>wrote: >>> >>>Dmitry and Zend, >>> >>>Thank you for sharing your code. I look forward to playing

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 4:54 PM > Hi Christian, > > On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller wrote: > It is not a bug. FALSE as a return value of substr() is the identificator > for an error (e.g. invalid arguments), as it is stated

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On Fri, Feb 27, 2015 at 6:40 PM, Jordi Boggiano wrote: > On 27/02/2015 15:19, Andi Gutmans wrote: > >> >> On Feb 27, 2015, at 7:12 AM, Anthony Ferrara >>> wrote: >>> >>> Dmitry and Zend, >>> >>> Thank you for sharing your code. I look forward to playing with it. >>> >>> Perhaps after 7 stabiliz

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Hi Christian, On Fri, Feb 27, 2015 at 3:38 PM, Christian Stoller wrote: > It is not a bug. FALSE as a return value of substr() is the identificator > for an error (e.g. invalid arguments), as it is stated in the > documentation: > [...] > "It is documented that way" and "it is not a bug" are tw

Re: [PHP-DEV] Re: Zend JIT Open Sourced

On 27/02/2015 15:19, Andi Gutmans wrote: On Feb 27, 2015, at 7:12 AM, Anthony Ferrara wrote: Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and th

Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

On Fri, Feb 27, 2015 at 4:25 PM, Sebastian Bergmann wrote: > Am 27.02.2015 um 01:29 schrieb Matthew Weier O'Phinney: > > - PHPUnit passes a boolean false to `debug_backtrace()`... which is > documented > > as expecting an integer! (There are actually several constant values it > > accepts, al

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Cristian, >> All those are due to a bug in substr(), that we see now only thanks to >> proper type identification. There is no reason for substr() to ever return >> a boolean. It really needs to be fix to always return a string. >> >> Damien > > It is not a bug. FALSE as a return value of substr()

Re: [PHP-DEV] Re: About optimization for compiler

On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand wrote: > > > Am 27.02.2015 um 16:12 schrieb Xinchen Hui : > > > > On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand > wrote: > >> Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > >> > >> Hey: > >> > >> On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui > wrote:

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

+1 on Sebastian's suggestion. =) I volunteer to either update the RFC or create a new one to resolve this once "Exceptions in the engine" passes (which looks like a reality already to me). Just tell me which approach I should take and I'll happily write the RFC. []s, On Fri, Feb 27, 2015 at 9:4

[PHP-DEV] Re: About optimization for compiler

On Fri, Feb 27, 2015 at 6:08 PM, Bob Weinand wrote: > Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > Hey: > > On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote: > > Hey Internals: > > I was looking Bob's switch optimization.. > > And, I am not against this switch optimization.. > > I ref

Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

Am 27.02.2015 um 01:29 schrieb Matthew Weier O'Phinney: > - PHPUnit passes a boolean false to `debug_backtrace()`... which is documented > as expecting an integer! (There are actually several constant values it > accepts, all of which are integer values.) In this case, PHPUnit is relying > on

Re: [PHP-DEV] Re: About optimization for compiler

> Am 27.02.2015 um 16:12 schrieb Xinchen Hui : > > On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand wrote: >> Am 27.02.2015 um 07:53 schrieb Xinchen Hui : >> >> Hey: >> >> On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote: >> >> Hey Internals: >> >> I was looking Bob's switch optimization

Re: [PHP-DEV] Re: Zend JIT Open Sourced

Am 27.02.2015 um 16:12 schrieb Anthony Ferrara: > Thank you for sharing your code. I look forward to playing with it. > > Perhaps after 7 stabilizes (and ships) you could write up your > thoughts around it? Why decisions were made and the findings that you > have? What Joe and Anthony said :-) T

Re: [PHP-DEV] Re: Zend JIT Open Sourced

> On Feb 27, 2015, at 7:12 AM, Anthony Ferrara wrote: > > Dmitry and Zend, > > Thank you for sharing your code. I look forward to playing with it. > > Perhaps after 7 stabilizes (and ships) you could write up your > thoughts around it? Why decisions were made and the findings that you > have?

[PHP-DEV] Re: About optimization for compiler

On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand wrote: > Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > Hey: > > On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui wrote: > > Hey Internals: > > I was looking Bob's switch optimization.. > > And, I am not against this switch optimization.. > > I ref

[PHP-DEV] Re: Zend JIT Open Sourced

Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Thanks again Anthony On Fri, Feb 27, 2015 at 7:10 AM, Dmitry Stogov w

[PHP-DEV] Re: About optimization for compiler

> Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > Hey: > > On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui > wrote: >> Hey Internals: >> >> I was looking Bob's switch optimization.. > And, I am not against this switch optimization.. > > I referring it to show wher

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

On 27/02/2015 14:31, Sebastian Bergmann wrote: Am 23.02.2015 um 19:15 schrieb Nikita Popov: 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

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

From: Damien Tournoud [mailto:d...@damz.org], Sent: Friday, February 27, 2015 2:38 PM > Hi Zeev, > > On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote: > > > Drupal homepage: One new E_DEPRECATED warning, which seems to catch a > > real bug, or at least faulty looking code: > > $path = tri

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

Am 23.02.2015 um 19:15 schrieb Nikita Popov: > 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, a

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On Fri, Feb 27, 2015 at 2:57 PM, Lester Caine wrote: > On 27/02/15 13:45, Benjamin Eberlei wrote: > >>> Drupal admin interface (across the all pages): One new E_DEPRECATED > >>> > > warning, which again seems to catch a real bug - stripslsahes() > operating > >>> > > on a boolean. > >>> > > > >

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On Fri, Feb 27, 2015 at 2:37 PM, Damien Tournoud wrote: > Hi Zeev, > > On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote: > > > Drupal homepage: One new E_DEPRECATED warning, which seems to catch a > > real bug, or at least faulty looking code: > > $path = trim($path, '/'); // raises E_DE

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 27/02/15 13:45, Benjamin Eberlei wrote: >>> Drupal admin interface (across the all pages): One new E_DEPRECATED >>> > > warning, which again seems to catch a real bug - stripslsahes() >>> > > operating >>> > > on a boolean. >>> > > >> > >> > All those are due to a bug in substr(), that we see

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On Fri, Feb 27, 2015 at 2:37 PM, Damien Tournoud wrote: > Hi Zeev, > > On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote: > > > Drupal homepage: One new E_DEPRECATED warning, which seems to catch a > > real bug, or at least faulty looking code: > > $path = trim($path, '/'); // raises E_DE

Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

Matthew, Thanks a bunch for going through this and writing such a detailed report. On 27/02/2015 00:29, Matthew Weier O'Phinney wrote: ### STHv5 [snip] Analysis I did not expect the float value to be coerced, particularly as it had a fractional part. Yes, I understand that this is how

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Hi Zeev, On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote: > Drupal homepage: One new E_DEPRECATED warning, which seems to catch a > real bug, or at least faulty looking code: > $path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean > false. > return $path; > > Drupal ad

Re: [PHP-DEV] A different user perspective on scalar type declarations

On 27/02/15 13:12, François Laupretre wrote: > If we allow for trailing blanks, we'll allow the same set of chars > that is already allowed for leading blanks. > > I say'blanks' and not 'whitespaces', because here is the list > currently allowed as leading blank (with ascii values) : Space (32) ,

RE: [PHP-DEV] A different user perspective on scalar type declarations

Hi, If we allow for trailing blanks, we'll allow the same set of chars that is already allowed for leading blanks. I say'blanks' and not 'whitespaces', because here is the list currently allowed as leading blank (with ascii values) : Space (32) , tab (9) , linefeed (10), carriage-return (13),

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

> -Original Message- > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > Sent: Friday, February 27, 2015 1:19 PM > To: Dmitry Stogov > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > > > On Fri, Feb 27, 2015 at 9:44 AM,

[PHP-DEV] Re: Zend JIT Open Sourced

Dmitry, Thanks for the opportunity to read, that's cool ;) Cheers Joe On Fri, Feb 27, 2015 at 12:10 PM, Dmitry Stogov wrote: > Hi, > > With the recent discussions of JIT/AOT and the good progress we made on > PHP-7, we decided to open up the JIT experiment we've been working on. > > https:

Re: [PHP-DEV] Feature request and RFC

Thomas Gielfeldt wrote on 24/02/2015 16:17: Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and perhaps get a voting on. I think the reason t

[PHP-DEV] Zend JIT Open Sourced

Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instr

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On Fri, Feb 27, 2015 at 12:18 PM, Benjamin Eberlei wrote: > > > On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov wrote: > >> I've added the link to the patch >> >> https://github.com/php/php-src/pull/1125/files >> > > Thanks! > > First, the necessary PHPUnit changes (dev-master) to avoid errors: >

Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI

Yasuo Ohgaki wrote on 27/02/2015 03:44: Hi all, This is RFC for removing "allow_url_include" INI option. [1] During "Script only include" RFC[2] discussion, stream wrapper issue is raised. I was thinking this issue as a separate issue, but it seems others are not. I'm not convinced by the arg

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On Fri, Feb 27, 2015 at 9:44 AM, Dmitry Stogov wrote: > I've added the link to the patch > > https://github.com/php/php-src/pull/1125/files > Thanks! First, the necessary PHPUnit changes (dev-master) to avoid errors: https://gist.github.com/beberlei/8a33ae940829f1186da2 - Doctrine DBAL testsu

Re: [PHP-DEV] A different user perspective on scalar type declarations

Hi Zeev, On Fri, Feb 27, 2015 at 2:48 AM, Zeev Suraski wrote: > You may have a point there. As Francois said, he was in favor of allowing > leading and trailing spaces. I'll definitely reconsider. > If we consider existing code, leading/trailing spaces may need to be allowed. Without consider

RE: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

> - PHPUnit passes a boolean false to `debug_backtrace()`... which is > documented > as expecting an integer! (There are actually several constant values it > accepts, all of which are integer values.) In this case, PHPUnit is > relying > on the fact that the engine casts booleans to the inte

Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI

Hi Xinchen, On Fri, Feb 27, 2015 at 4:45 PM, Xinchen Hui wrote: > Sorry, but I am confused by the point, do you want to disable include > a remote php file or not? > I think the RFC title was misleading. I've changed to Precise URL include control Thank you for your feedback. Regards, -- Ya

Re: [PHP-DEV] A different user perspective on scalar type declarations

On 27/02/15 01:29, François Laupretre wrote: > Yes. Same conversion rules : empty string and "0" are false, all the rest is > true. > > For consistency reasons, we can extend the "0" case to accept leading zeroes > and leading and trailing blanks, as for a numeric string. Just been checking and

Re: [PHP-DEV] [RFC][DISCUSSION] Remove allow_url_include INI

Hi Xinchen, On Fri, Feb 27, 2015 at 4:45 PM, Xinchen Hui wrote: > Sorry, but I am confused by the point, do you want to disable include > a remote php file or not? > > if yes, how about with allow_url_fopen? > > eval(file_get_contents(http://xx/)); > > thanks > My objective is to disable "l

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

Am 27.02.2015 um 09:53 schrieb Xinchen Hui: > I noticed different version of xdebug, could you try without it? Thank you for bringing Xdebug to my attention. You are right, it appears to be related to Xdebug. Without Xdebug $ php -v PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyr

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

check xdebug Thanks. Dmitry. On Fri, Feb 27, 2015 at 11:51 AM, Sebastian Bergmann wrote: > Am 27.02.2015 um 09:30 schrieb Xinchen Hui: > > maybe related to your own build? > > The test in the PHPUnit test suite fails with > >PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) >Copyright (c)

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

Hey: On Fri, Feb 27, 2015 at 4:51 PM, Sebastian Bergmann wrote: > Am 27.02.2015 um 09:30 schrieb Xinchen Hui: >> maybe related to your own build? > > The test in the PHPUnit test suite fails with > >PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) >Copyright (c) 1997-2015 The PHP Group >

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

Am 27.02.2015 um 09:30 schrieb Xinchen Hui: > maybe related to your own build? The test in the PHPUnit test suite fails with PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Xdeb

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

I've added the link to the patch https://github.com/php/php-src/pull/1125/files Thanks. Dmitry. On Fri, Feb 27, 2015 at 11:03 AM, Benjamin Eberlei wrote: > Zeev, > > On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote: > > > All, > > > > We've been working in the last few days to test and t

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

Hey: On Fri, Feb 27, 2015 at 4:06 PM, Sebastian Bergmann wrote: > While working on PHPUnit today I noticed one test of its own test > suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of > this can be found at > >https://github.com/sebastianbergmann/phpunit/issues/1630 > >

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

On 27 February 2015 at 08:20, Leigh wrote: > Looking through git blames, this property has been protected for a long time. > > Possibly related (although not at all sure), Dmitry made some changes > to zend_read_property() > > https://github.com/php/php-src/commit/3e31838d19750d287431d22e9290856ec

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

On 27/02/2015 09:06, Sebastian Bergmann wrote: While working on PHPUnit today I noticed one test of its own test suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of this can be found at https://github.com/sebastianbergmann/phpunit/issues/1630 It's actually very weird.

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

Am 27.02.2015 um 09:14 schrieb Remi Collet: > Hmmm http://3v4l.org/QST64 No clue why PHP 5.6.5 seems to have worked for that reproducing script here earlier. Tried it again and, of course, it also fails with "my" PHP 5.6.5. Looks the like the reproducing script was not the right one. :-/ --

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

On Fri, Feb 27, 2015 at 9:20 AM, Leigh wrote: > On 27 February 2015 at 08:06, Sebastian Bergmann > wrote: > > While working on PHPUnit today I noticed one test of its own test > > suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of > > this can be found at > > > >https://g

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

On 27 February 2015 at 08:06, Sebastian Bergmann wrote: > While working on PHPUnit today I noticed one test of its own test > suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of > this can be found at > >https://github.com/sebastianbergmann/phpunit/issues/1630 > > Florian M

Re: [PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 27/02/2015 09:06, Sebastian Bergmann a écrit : > While working on PHPUnit today I noticed one test of its own test > suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details > of this can be found at > > https://github.com/sebastianbergman

Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

Matthew, On Fri, Feb 27, 2015 at 1:29 AM, Matthew Weier O'Phinney wrote: > I've taken some time the last couple days to compile both the Scalare Type > Hints > v0.5 (heretofor STHv5) and Coercive Scalar Type Hints (heretofore > STHcoerce) > patches and test some code against them. > > In each ca

[PHP-DEV] BC break between PHP 5.6.5 and PHP 5.6.6

While working on PHPUnit today I noticed one test of its own test suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of this can be found at https://github.com/sebastianbergmann/phpunit/issues/1630 Florian Margaine reduced the problem to the following minimal, self-contained

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

Zeev, On Fri, Feb 27, 2015 at 12:57 AM, Zeev Suraski wrote: > All, > > We've been working in the last few days to test and tune the Coercive STH > patch. I think the results are quite nice, and surprisingly better than > one might have expected. > Can we try the patch ourselves? I would love t

  1   2   >