[PHP-DEV] Github integration with AppVeyor

Hi, There's yet another CI service there called AppVeyor.com. It provides same functionality Travis does, but for Windows. A corresponding PR https://github.com/php/php-src/pull/2169 aims to implement the integration. I'm writing to inform the community and to discuss. The service is free for

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> > > My point is that you are adding 'testing tools' which are only any use > > to test themselves and not the actual interface? It's creating > > additional code that has nothing to do with testing that PDO is working > > cleanly properly across all databases, especially if it does not expect >

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> My point is that you are adding 'testing tools' which are only any use > to test themselves and not the actual interface? It's creating > additional code that has nothing to do with testing that PDO is working > cleanly properly across all databases, especially if it does not expect > a working

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-10-26

Results for project PHP master, build date 2016-10-26 06:25:58+03:00 commit: 4054d1c previous commit:31e986b revision date: 2016-10-25 22:13:46+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Strict types indicator in backtraces

Hi all, I've written a small patch to add a "strict_types" key to the backtrace information for functions. https://github.com/php/php-src/pull/2177 The idea here is to be able to see more easily whether a parameter may have had it's type changed or not during a trace. Thoughts and opinions?

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

On 26/10/16 16:56, Adam Baratz wrote: >> >> Since PDO is an interface to third party databases this seems totally >> out of place in PHP. Prepared statements are a sensible mechanism for >> for anyone wanting secure access to those database, so what is the point >> of this code. > > I don't want

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation

> > Since PDO is an interface to third party databases this seems totally > out of place in PHP. Prepared statements are a sensible mechanism for > for anyone wanting secure access to those database, so what is the point > of this code. I don't want to solve for database access. I want to create

RE: [PHP-DEV] JIT for PHP project

Hi Dmitry, Thanks for the info. Probably I'm just too curious :) Please count on me once it becomes relevant to hand out some part. Regards Anatol > -Original Message- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Wednesday, October 26, 2016 1:31 PM > To: Anatol Belski

[PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

Greetings, As suggested by several reviewers of a PR[1] I recently submitted, I'd like to get feedback on letting custom Iterators be used in the current, next, reset, and key functions. If this is something to move forward with, I'll need some help with the RFC process. Recent experiences

Re: [PHP-DEV] JIT for PHP project

Hi Anatol, The project is in the very early development stage. Now, JIT passes almost all PHPT tests, makes 3 times speed-up on bench.php and no significant difference on real-life apps (+/-5% depended on opcache.jit setting. We are hardly working, implementing new ideas... I think it's

Re: [PHP-DEV] [RFC] [VOTE] Counting of non-countable objects

> On 25 Oct 2016, at 19:41, Craig Duncan wrote: > > Hi Dan, > > The manual already says what is allowed: > "Parameters: array_or_countable An array or Countable object." Thanks. There is a small possibility I missed that already being there. cheers Dan

RE: [PHP-DEV] JIT for PHP project

Hi Dmitry, > -Original Message- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Thursday, September 1, 2016 1:57 PM > To: PHP internals list > Cc: Zeev Suraski ; Xinchen Hui > Subject: [PHP-DEV] JIT for PHP project > >