Re: [PHP-DEV] RFC Draft: Comprehensions

On 21 March 2019 00:39:20 GMT+00:00, Robert Hickman wrote: >For my use case of PHP, get some content from a DB and dump it into a >template, I don't see much benefit to generators. With respect, so what? I never said that every use case benefits from generators, nor are we discussing whether

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

Hi, The vote seems currently closed, but as long as it says: Proposed PHP version: PHP 7.4 I won't be voting for it. This should squarely just be targetted at PHP 8.0. cheers, Derick On Thu, 21 Mar 2019, Dmitry Stogov wrote: > Hey, > > I'm starting the vote on JIT RFC. > > >

[PHP-DEV] PHP 7.3.4RC1 is available for testing

Hi, PHP 7.3.4RC1 has just been released and can be downloaded from: Or use the git tag: php-7.3.4RC1 The Windows binaries are available at: Please test it carefully, and report any bugs in the bug system. 7.3.4 should be

Re: [PHP-DEV] RFC Draft: Comprehensions

I was only making a point for where a non-generator version of comprehensions could be useful, under the premise "Therefore, a lazy-evaluating syntax is more powerful, in that it can do everything an eager-evaluating one can do *and more*.". This implies that it dosn't have any downsides, whereas

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

On Thu, 21 Mar 2019, Derick Rethans wrote: > Hi, > > The vote seems currently closed, but as long as it says: > > Proposed PHP version: PHP 7.4 The RFC doesn't say that, but the link in your email was: https://wiki.php.net/rfc/jit Doesn't help

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

On Thu, Mar 21, 2019 at 12:58 PM Dmitry Stogov wrote: > Hey, > > I'm starting the vote on JIT RFC. > > > https://wiki.php.net/rfc/jit > > > > The voting period is one week, until Thursday 28-03-2019 GMT. > > > Since the initial announcement and

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

Hey Joe, Voting rules nothing say about "complex features" and 2 weeks voting period. If you liked to change this, you might do it together with 50%+1 -> 2/3 majority change. If you agree, I can extend voting period "pseudo proportionally" (to be 1.5 week), but I don't like to lose the

Re: [PHP-DEV] Offset-only results from preg_match

On Wed, Mar 20, 2019 at 4:35 PM C. Scott Ananian wrote: > On Tue, Mar 19, 2019 at 10:58 AM Nikita Popov > wrote: > >> After thinking about this some more, while this may be a minor >> performance improvement, it still does more work than necessary. In >> particular the use of OFFSET_CAPTURE

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

On Thu, 21 Mar 2019 at 12:15, Derick Rethans wrote: > > I won't be voting for it. This should squarely just be targetted at PHP > 8.0. > Same thoughts here, extended to I don't think we should be having any dramatic changes in 7.4. Although the improvements that have been made from 5.6 to 7.x

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

Such complex and far reaching features should clearly have a two week voting period, please update the RFC. Cheers Joe On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov wrote: > Hey, > > I'm starting the vote on JIT RFC. > > >

[PHP-DEV] PCRE callouts

Hi internals, PCRE has support for "callouts", which allow calling a custom function at specified points during pattern matching. This functionality is documented at https://www.pcre.org/current/doc/html/pcre2callout.html. I've implemented a prototype for exposing this functionality in PHP at

[PHP-DEV] [RFC] [VOTE] JIT

Hey, I'm starting the vote on JIT RFC. https://wiki.php.net/rfc/jit The voting period is one week, until Thursday 28-03-2019 GMT. Since the initial announcement and following discussions, RFC was imprved and implementation extended with

Re: [PHP-DEV] RFC Draft: Comprehensions

On Thu, 21 Mar 2019 at 11:00, Robert Hickman wrote: > I was only making a point for where a non-generator version of > comprehensions could be useful, under the premise "Therefore, a > lazy-evaluating syntax is more powerful, in that it can do everything > an eager-evaluating one can do *and

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

On Thu, Mar 21, 2019 at 1:41 PM Dan Ackroyd wrote: > On Thu, 21 Mar 2019 at 12:15, Derick Rethans wrote: > > > > > I won't be voting for it. This should squarely just be targetted at PHP > > 8.0. > > > > Same thoughts here, extended to I don't think we should be having any > dramatic changes in

Re: [PHP-DEV] RFC Draft: Comprehensions

On Thu, 21 Mar 2019 at 15:21, Robert Hickman wrote: > In this case nextIf() would have to be implemented something like: > > function nextif($someCondition) { > foreach($this->iteratorValue as $x) { > if( yield $x; > } > } > } > > iterator_to_array would need

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

On 3/21/19 4:27 PM, Joe Watkins wrote: > Afternoon Dmitry, > > > If you liked to change this, you might do it together with 50%+1 -> > 2/3 majority change. > > The super majority RFC was already accepted ... > > > If you agree, I can extend voting period "pseudo proportionally" (to > be

Re: [PHP-DEV] RFC Draft: Comprehensions

> But $filteredArrayIterator->next() is actually $arrayIterator->next() with > a built-in if check, so you could also picture it as doing this: > > while ( $element = $arrayIterator->nextIf ( someCondition ) ) { > $newArray[] = $element; > } > In this case nextIf() would have to be

Re: [PHP-DEV] RFC Draft: Comprehensions

On Wed, Mar 20, 2019, at 5:44 PM, Rowan Collins wrote: > On 20/03/2019 20:39, Stanislav Malyshev wrote: > > Hi! > > > >> It's not that you can't make an array into a generator, but you can't make > >> an eagerly-evaluated expression into a lazily-evaluated one. > > Not sure what you mean here. >

[PHP-DEV] PHP 7.2.17RC1 ready for testing

Hi, PHP 7.2.17 RC1 was just released and can be downloaded from: https://downloads.php.net/~pollita Or using the git tag: php-7.2.17RC1 The Windows binaries are available at: http://windows.php.net/qa/ Please test it carefully, and report any bugs in the bug system. 7.2.17 should be

[PHP-DEV] Re: [VOTE] New custom object serialization mechanism

On Fri, Mar 1, 2019 at 4:08 PM Nikita Popov wrote: > Hi internals, > > I have opened voting on > https://wiki.php.net/rfc/custom_object_serialization. The vote will be > open until 2019-03-15. > > You can find the discussion thread for this proposal here: > https://externals.io/message/103823 >

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

Afternoon Dmitry, > If you liked to change this, you might do it together with 50%+1 -> 2/3 majority change. The super majority RFC was already accepted ... > If you agree, I can extend voting period "pseudo proportionally" (to be 1.5 week), but I don't like to lose the following week. I'm not

[PHP-DEV] Re: Convert ext/xml to use an object instead of resource

On Tue, Feb 12, 2019 at 4:00 PM Nikita Popov wrote: > Hi internals, > > The ext/xml extension currently has GC issues, see > https://bugs.php.net/bug.php?id=76874. The tl;dr is that uses of > xml_parser will usually result in a cyclic structure, but resources do not > support cycle GC. This

Re: [PHP-DEV] PHP on OSS-fuzz

Hey! On 17/03/2019 22:23, Stanislav Malyshev wrote: > Hi! > > Looking at the recent PHP security issues, it is clear that many of them > are stemming from corner cases in various format-parsing code, and most > of them either is or can be found by fuzzers. > > Thus, I've made an initial

[PHP-DEV] Re: [RFC] Abolish Short Votes

On 21.03.2019 at 19:20, Joe Watkins wrote: > I'd like to raise for discussion another minor, self contained change to > the voting RFC: > > https://wiki.php.net/rfc/abolish-short-votes +1 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

[PHP-DEV] [RFC] Abolish Short Votes

Evening internals, I'd like to raise for discussion another minor, self contained change to the voting RFC: https://wiki.php.net/rfc/abolish-short-votes This seems like another no-brainer to improve and clarify the voting process. As with abolishing narrow margins, I'm focused on this one

Re: [PHP-DEV] Offset-only results from preg_match

Quick status update. I tried to prototype this in pure PHP in the wikimedia/remex-html library using (?= .. ) around each regexp and ()...() around each captured expression (replacing the capture parens) to effectively bypass the string copy and return a bunch of zero-length strings. That didn't

Re: [PHP-DEV] Offset-only results from preg_match

ps. Just to put some numbers to it, using `psysh` on $html100 which contains the (Parsoid format) HTML for the [[en:Barack Obama]] article on Wikipedia. ``` >>> strlen($html100) => 2592386 >>> timeit -n1000 preg_match_all( '/(b)/', $html100, $m, PREG_OFFSET_CAPTURE ); => 22062 Command took

Re: [PHP-DEV] RFC Draft: Comprehensions

On Thu, 21 Mar 2019 at 16:15, Rowan Collins wrote: > > On Thu, 21 Mar 2019 at 15:21, Robert Hickman wrote: >> >> In this case nextIf() would have to be implemented something like: >> >> function nextif($someCondition) { >> foreach($this->iteratorValue as $x) { >> if(>

Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings

On Fri, 22 Mar 2019, 01:06 Benjamin Morel, wrote: > FWIW, I'd lean towards rejecting leading whitespace. That could be a good > BC break candidate for PHP 8! > > Ben > Ack: leaning towards same thought >

Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings

FWIW, I'd lean towards rejecting leading whitespace. That could be a good BC break candidate for PHP 8! Ben On Fri, 22 Mar 2019 at 00:33, Andrea Faulds wrote: > Hi again, > > I would proceed to a vote with this (and do intend to still), but the > response from internals has been very quiet.

[PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings

Hi again, I would proceed to a vote with this (and do intend to still), but the response from internals has been very quiet. Has it gotten lost among all the other things happening? :) I realise it's not a very exciting change of course, and there isn't much to discuss about it. It's pretty