Re: [PHP-DEV] Re: zpp and zend_string

2014-08-26 Thread Anatol Belski
Hi Tjerk, On Wed, August 27, 2014 07:34, Tjerk Meesters wrote: > Hi internals, > > > With the recent merge of int64 the `zend_string` type now uses `size_t` > to store its length, but ZPP (and friends) still use `int *` to store the > parsed string lengths. > > http://lxr.php.net/xref/PHP_TRUNK/Ze

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h

2014-08-26 Thread Anatol Belski
Hi Derick, On Tue, August 26, 2014 10:49, Derick Rethans wrote: > On Fri, 22 Aug 2014, Anatol Belski wrote: > > >> On Fri, August 22, 2014 17:17, Derick Rethans wrote: >> >>> On Fri, 22 Aug 2014, Anatol Belski wrote: >>> >>> On Fri, August 22, 2014 14:54, Derick Rethans wrote: >

[PHP-DEV] Re: [PHP-CVS] com php-src: fixes to string functions: ext/standard/php_string.h ext/standard/string.c

2014-08-26 Thread Anatol Belski
On Wed, August 27, 2014 01:32, Nikita Popov wrote: > On Mon, Aug 18, 2014 at 3:39 PM, Anatol Belski wrote: > > >> Commit:97e9d058f09c12161863e5c3832552eb5da3f3c6 >> Author:Anatol Belski Mon, 18 Aug 2014 15:39:38 >> +0200 >> Parents: 22dbb38d5e234f5987e226298ba9b86d9f9ea52a >> Br

[PHP-DEV] Re: zpp and zend_string

2014-08-26 Thread Tjerk Meesters
Hi internals, With the recent merge of int64 the `zend_string` type now uses `size_t` to store its length, but ZPP (and friends) still use `int *` to store the parsed string lengths. http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_API.c#519 This look like an oversight. Will this be fixed as well?

Re: [PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)

2014-08-26 Thread Andrea Faulds
On 20 Aug 2014, at 13:50, Andrea Faulds wrote: > I’m putting this RFC to a vote again as I haven’t heard any objections in the > past three days, and in the event something’s been missed, one week would be > long enough to spot it. > > Vote is here: https://wiki.php.net/rfc/closure_apply#vote

Re: [PHP-DEV] Remove generated VM from git?

2014-08-26 Thread Andrea Faulds
On 26 Aug 2014, at 22:17, Stas Malyshev wrote: > That's not an advantage. Having extra file in git is no problem at all, > we don't pay per byte, and somebody who can't handle regenerating the VM > file should not be messing with the VM (for one, they would notice the > problem immediately on ru

Re: [PHP-DEV] VCS access

2014-08-26 Thread Chris Wright
On 27 August 2014 00:05, Ferenc Kovacs wrote: > > > > On Tue, Aug 26, 2014 at 10:25 PM, Chris Wright wrote: >> >> Hi all >> >> I would like to request VCS access to php-src. I would like to be able >> to merge my own patches when (and only when) it is agreed they should >> be merged :-) >> >> Exi

Re: [PHP-DEV] VCS access

2014-08-26 Thread Ferenc Kovacs
On Tue, Aug 26, 2014 at 10:25 PM, Chris Wright wrote: > Hi all > > I would like to request VCS access to php-src. I would like to be able > to merge my own patches when (and only when) it is agreed they should > be merged :-) > > Existing contributions: > https://github.com/php/php-src/commits?au

Re: [PHP-DEV] Remove generated VM from git?

2014-08-26 Thread Stas Malyshev
Hi! > Why would a non-internals person want to build PHP from git? That’s Why not? It's an open-source project, isn't it? People may prefer using git, many integration systems (including PHP's own composer) rely on git. > just making things harder on themselves. Besides PHP itself (should > my p

[PHP-DEV] Remove generated VM from git?

2014-08-26 Thread Andrea Faulds
Hi! Spinning this discussion (removing generated VM from git) off into its own thread. On 26 Aug 2014, at 21:12, Nikita Popov wrote: > -1 on removing zend_vm_execute.h. Having to install php before I can build > php would be very inconvenient. I’d point out PHP already requires extra depende

[PHP-DEV] VCS access

2014-08-26 Thread Chris Wright
Hi all I would like to request VCS access to php-src. I would like to be able to merge my own patches when (and only when) it is agreed they should be merged :-) Existing contributions: https://github.com/php/php-src/commits?author=DaveRandom https://github.com/php/php-src/pulls/DaveRandom https:

Re: [PHP-DEV] Remove generated lexers from git?

2014-08-26 Thread Nikita Popov
On Tue, Aug 26, 2014 at 10:01 PM, Andrea Faulds wrote: > > On 26 Aug 2014, at 20:55, Nikita Popov wrote: > > > Currently our git repo contains files like zend_language_scanner.c, > > zend_ini_scanner.c, etc which are files generated by re2c. Historically > > these files have been included becaus

Re: [PHP-DEV] 5.4 security only

2014-08-26 Thread Chris Wright
On 26 August 2014 18:31, Stas Malyshev wrote: > Hi! > > >> Does anyone have any objections to this being included in 5.4? >> >> Thanks, Chris >> >> [1] >> https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89 > > I think it's ok for 5.4. > Great, thanks :-) -- P

Re: [PHP-DEV] Remove generated lexers from git?

2014-08-26 Thread Stas Malyshev
Hi! > On a similar theme, could we also get rid of the generated Zend VM, > and wire up zend_vm_gen.php to make like we wire up bison and re2c? That would make building PHP for non-internals person harder and the list of dependencies they need to get right longer. While providing zero added value

Re: [PHP-DEV] Remove generated lexers from git?

2014-08-26 Thread Andrea Faulds
On 26 Aug 2014, at 20:55, Nikita Popov wrote: > Currently our git repo contains files like zend_language_scanner.c, > zend_ini_scanner.c, etc which are files generated by re2c. Historically > these files have been included because re2c was not readily available on > many platforms. In the thread

[PHP-DEV] Remove generated lexers from git?

2014-08-26 Thread Nikita Popov
Hi internals! Currently our git repo contains files like zend_language_scanner.c, zend_ini_scanner.c, etc which are files generated by re2c. Historically these files have been included because re2c was not readily available on many platforms. In the thread on bison 3 compatibility [1] there was so

Re: [PHP-DEV] 5.4 security only

2014-08-26 Thread Stas Malyshev
Hi! > Does anyone have any objections to this being included in 5.4? > > Thanks, Chris > > [1] > https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89 I think it's ok for 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --

[PHP-DEV] 1948 Piscinas espectaculares

2014-08-26 Thread construccion de piscinas
--- Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa. http://www.avast.com

Re: [PHP-DEV] 5.4 security only

2014-08-26 Thread Chris Wright
Hi Stas On 19 August 2014 00:59, Stas Malyshev wrote: > Hi! > > Moving this out of other topics into its own: according to the release > RFC, we should have 5.4 have 2 years of bugfixes & one year of security > fixes. Since 5.4 was released in March 2012, we're already past 2 year > mark. However

Re: [PHP-DEV] Re: [VOTE] Abstract Syntax Tree

2014-08-26 Thread Ferenc Kovacs
On Tue, Aug 26, 2014 at 1:58 AM, Andrea Faulds wrote: > > On 26 Aug 2014, at 00:53, Benjamin Eberlei wrote: > > > Depends, registering for shutdown handlers and catching fatals is a > pretty > > common thing. If EngineException does not get caught, it should produce > an > > E_FATAL again with t

[PHP-DEV] Re: Fwd: date extension broken tests

2014-08-26 Thread Derick Rethans
Hey, not sure if my mail made it over the weekend... connectivity was not great. On Mon, 25 Aug 2014, Dmitry Stogov wrote: > Could you please take a look into these tests failures. I actually, > think that the new behavior is right. Calls to parent::__constructor() > shouldn't change value of

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h

2014-08-26 Thread Derick Rethans
On Fri, 22 Aug 2014, Anatol Belski wrote: > On Fri, August 22, 2014 17:17, Derick Rethans wrote: > > On Fri, 22 Aug 2014, Anatol Belski wrote: > > > >> On Fri, August 22, 2014 14:54, Derick Rethans wrote: > >> > >>> Yeah, those datatypes should already be there. What needs fixing > >>> to make it