Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Rowan Collins]

On 1 November 2017 17:47:55 GMT+00:00, BohwaZ  wrote:
>I can't find the place where we can see the voting history? Last time I
>checked the page last week it was 6 to 5 or something like that.

See my email in this thread from a couple of days ago. Last vote was a yes, but 
probably too late, leaving 6:6, which means no consensus to merge this 
implementation.

Hopefully we can get some momentum behind a more general API that allows this 
feature in a way that will be more positively received.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[BohwaZ]

On Mon, 30 Oct 2017 20:11:18 + / Rowan Collins
 said :

> On 30/10/2017 03:14, Dan Ackroyd wrote:
> > The vote for this should have ended..3 days ago.
> >
> > At which point I believe the vote was actually passing.
> 
> 
> Hm, that's awkward!
> 
> For the record:
> 
> - voting was announced on the evening of the 9th "for two weeks"
> which would imply the evening of the 23rd
> - however, the e-mail also said "Vote will end on Wednesday the 25th
> of October. "

Don't know where that 9th is from? I posted my email around 11 am on
Tusday October 10th, so +2 weeks is Tuesday October 24th, but I thought
it would close at midnight, so on the 25th :)

> - the wiki page states "Vote closing on Oct 27, 2017."

My bad there, sorry, I counted two weeks from when someone told me to
put the date on the wiki (which I forgot to do).

> - https://php-rfc-watch.beberlei.de/ lists "daverandom" voting No at 
> 2017-10-28T07:28:00+ (*mutters something about relative date
> display being uselessly vague*)
> 
> It's possible that daverandom was several hours west of Greenwich at
> the time (e.g. in North America), where it was still late on October
> 27th. So taking the latest of the three published closing dates, and
> applying the most generous time zone, it's possible that all the
> votes were valid.

Ah yeah didn't thought of that, but I'm in NZ, so the dates I
talked about were UTC+13.

> In my opinion, the very fact that it was this close suggests that
> there is not consensus in favour of the change, and therefore it
> would be reasonable to err on the side of caution, and not adopt the
> change.

Agreed.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[BohwaZ]

On Wed, 01 Nov 2017 19:08:56 + / Rowan Collins
 said :

> On 1 November 2017 17:47:55 GMT+00:00, BohwaZ  wrote:
> >I can't find the place where we can see the voting history? Last
> >time I checked the page last week it was 6 to 5 or something like
> >that.
> 
> See my email in this thread from a couple of days ago. Last vote was
> a yes, but probably too late, leaving 6:6, which means no consensus
> to merge this implementation.
> 
> Hopefully we can get some momentum behind a more general API that
> allows this feature in a way that will be more positively received.

OK, thanks. I marked the RFC as rejected.

I'll be leaving this list now as this marks the end of my
contributions to PHP, as my free time is very limited and I want to
spend it on useful activities.

So good luck to the next person who will rewrite that part of PDO, if
that happens.

Thanks everyone :)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Rowan Collins]

Just for the record, this question:


Don't know where that 9th is from? I posted my email around 11 am on
Tusday October 10th


Is answered by this sentence:


Ah yeah didn't thought of that, but I'm in NZ, so the dates I
talked about were UTC+13.



I'm in Europe/London time, so 11am for you was 11pm the night before for 
me. For anyone reading in North America, it was still the previous 
afternoon.


Man I hate time zones! ;)


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Stanislav Malyshev]

Hi!

> Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1].
> 
> 
> Voting will be open for 2 weeks (until November 15th).

Something I am missing here. RFC is talking about removing indents from
heredoc text, but the vote says "Allow for the closing marker to be
indented?" and does not mention that indenting closing marker also
changes how the rest of the heredoc is parsed. Is this still the case?



-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Dan Ackroyd]

Stanislav Malyshev  wrote:
>
> Something I am missing here. RFC is talking about removing indents from
> heredoc text, but the vote says "Allow for the closing marker to be
> indented?" and does not mention that indenting closing marker also
> changes how the rest of the heredoc is parsed. Is this still the case?


>From the body of the RFC:

"To enable for the closing marker to be indented, ... The indentation
of the closing marker dictates the amount of whitespace to strip from
each line within the heredoc/nowdoc"

That's about 3 lines of text into the RFC. Presumably the RFC didn't
think the whole concept being voted on needed to be repeated in the
voting option. Perhaps it should have been but:

Christopher Jones wrote:
> I'm going to have to assume so and vote No.

It is better to ask questions during the discussion phase of an RFC,
but if you do have a question during the voting period, you're still
allowed to ask rather than voting based on assumptions.

> PS. RFC writers: please take care when writing specs.

Please don't use passive aggressive 'helpful hints' like this. For example:

"RFC voters - please read the RFC during the RFC period and ask
questions then. ;-)" is an irritating way of writing this.

A way of writing it that is more conducive to a productive discussion is:

I think this is covered in the RFC text. Does the line I picked out
above, give a clear description for what that vote is for?

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 2/11/17 8:58 am, Stanislav Malyshev wrote:

Hi!


Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1].


Voting will be open for 2 weeks (until November 15th).

Something I am missing here. RFC is talking about removing indents from
heredoc text, but the vote says "Allow for the closing marker to be
indented?" and does not mention that indenting closing marker also
changes how the rest of the heredoc is parsed. Is this still the case?




I'm going to have to assume so and vote No.

Chris

PS. RFC writers: please take care when writing specs.


--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

Hi internals!


Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1].


Voting will be open for 2 weeks (until November 15th).


Thanks,

Tom


[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes

Re: [PHP-DEV] RFC - Zend VM Pause API

[Dmitry Stogov]

or just change execute_data->opline...


From: Dmitry Stogov
Sent: Wednesday, November 1, 2017 12:14:22 PM
To: Haitao Lv
Cc: PHP Internals
Subject: Re: [PHP-DEV] RFC - Zend VM Pause API


after zend_interrupt_function() callback VM continues execution using 
EG(current_execute_data).

callback may modify it in any way (e.g. unwind stack, or switch to another 
co-routine or continuation).


Thanks. Dmitry.


From: Haitao Lv 
Sent: Wednesday, November 1, 2017 11:54:54 AM
To: Dmitry Stogov
Cc: PHP Internals
Subject: Re: [PHP-DEV] RFC - Zend VM Pause API

It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
only execute the interrupt_function and continue the current execution.

However, my RFC propose to stop the current execution.

On 1 Nov 2017, at 16:07, Dmitry Stogov 
> wrote:

Hi,

It should be possible do similar things using EG(vm_interrupt) and 
zend_interrupt_function() callback (introduced in php-7.1)
ext/pcntl implements asynchronous signal handling using this.

Thanks. Dmitry.

From: Haitao Lv >
Sent: Wednesday, November 1, 2017 4:19:07 AM
To: PHP Internals
Subject: [PHP-DEV] RFC - Zend VM Pause API

Hi, internals,

I propose to introduce a new zend vm pause api, and here is the RPF

https://wiki.php.net/rfc/zend-vm-pause-api

Please gave your comment.

Thank you.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Zend VM Pause API

[Haitao Lv]

To make the discussion more detailed, please allow me to offer my 
implementation of use land coroutine(Fiber).

https://github.com/php/php-src/compare/master...fiberphp:fiber-ext?expand=1


> On 1 Nov 2017, at 17:32, Haitao Lv  wrote:
> 
> Suppose we have a internal Coroutine class and it has a resume() method.
> 
> In order to resume the coroutine, we have to call the resume() function.
> 
> As the resume function is a internal method defined in c, we need call
> 
> zend_execute_ex(backuped_execute_data)
> 
> to resume the zend execution.
> 
> If we need to pause the coroutine, we set the EG(vm_interrupt) and 
> interrupt_function,
> and switch the execute data and stack. The zend vm will execute the old 
> online.
> 
> However, we will never see the resume() method returned and never get its 
> return value.
> 
>> On 1 Nov 2017, at 17:14, Dmitry Stogov  wrote:
>> 
>> after zend_interrupt_function() callback VM continues execution using 
>> EG(current_execute_data).
>> callback may modify it in any way (e.g. unwind stack, or switch to another 
>> co-routine or continuation).
>> 
>> Thanks. Dmitry.
>> From: Haitao Lv 
>> Sent: Wednesday, November 1, 2017 11:54:54 AM
>> To: Dmitry Stogov
>> Cc: PHP Internals
>> Subject: Re: [PHP-DEV] RFC - Zend VM Pause API 
>> 
>> It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
>> only execute the interrupt_function and continue the current execution.
>> 
>> However, my RFC propose to stop the current execution.
>> 
>>> On 1 Nov 2017, at 16:07, Dmitry Stogov  wrote:
>>> 
>>> Hi,
>>> 
>>> It should be possible do similar things using EG(vm_interrupt) and 
>>> zend_interrupt_function() callback (introduced in php-7.1)
>>> ext/pcntl implements asynchronous signal handling using this.
>>> 
>>> Thanks. Dmitry.
>>> From: Haitao Lv 
>>> Sent: Wednesday, November 1, 2017 4:19:07 AM
>>> To: PHP Internals
>>> Subject: [PHP-DEV] RFC - Zend VM Pause API 
>>> 
>>> Hi, internals,
>>> 
>>> I propose to introduce a new zend vm pause api, and here is the RPF
>>> 
>>> https://wiki.php.net/rfc/zend-vm-pause-api
>>> 
>>> Please gave your comment.
>>> 
>>> Thank you.
>>> 
>>> 
>>> 
>>> -- 
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> 
> 
> 
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[Derick Rethans]

On Mon, 30 Oct 2017, Rowan Collins wrote:

> On 30/10/2017 03:14, Dan Ackroyd wrote:
> > The vote for this should have ended..3 days ago.
> > 
> > At which point I believe the vote was actually passing.
> 
> 
> Hm, that's awkward!
> 
> For the record:
> 
> - voting was announced on the evening of the 9th "for two weeks" which would
> imply the evening of the 23rd
> - however, the e-mail also said "Vote will end on Wednesday the 25th of
> October. "
> - the wiki page states "Vote closing on Oct 27, 2017."
> - https://php-rfc-watch.beberlei.de/ lists "daverandom" voting No at
> 2017-10-28T07:28:00+ (*mutters something about relative date display being
> uselessly vague*)
> 
> It's possible that daverandom was several hours west of Greenwich at the time
> (e.g. in North America), where it was still late on October 27th. So taking
> the latest of the three published closing dates, and applying the most
> generous time zone, it's possible that all the votes were valid.
> 
> It's certainly clear that no *new* votes should be counted.
> 
> The last vote before that according to the rfc-watch tool was "salathe" on the
> 21st, so if daverandom's vote is *not* valid, the RFC passes 7:6; however, if
> daverandom's vote *is* valid, we have 7:7, and the RFC is declined.

7:6 is technically not "50%"+1. 50% of 13 is 6½, and 7 is not higher 
than 6½ + 1. :-)

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Zend VM Pause API

[Dmitry Stogov]

Hi,


It should be possible do similar things using EG(vm_interrupt) and 
zend_interrupt_function() callback (introduced in php-7.1)

ext/pcntl implements asynchronous signal handling using this.


Thanks. Dmitry.


From: Haitao Lv 
Sent: Wednesday, November 1, 2017 4:19:07 AM
To: PHP Internals
Subject: [PHP-DEV] RFC - Zend VM Pause API

Hi, internals,

I propose to introduce a new zend vm pause api, and here is the RPF

https://wiki.php.net/rfc/zend-vm-pause-api

Please gave your comment.

Thank you.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Zend VM Pause API

[Haitao Lv]

Suppose we have a internal Coroutine class and it has a resume() method.

In order to resume the coroutine, we have to call the resume() function.

As the resume function is a internal method defined in c, we need call

zend_execute_ex(backuped_execute_data)

to resume the zend execution.

If we need to pause the coroutine, we set the EG(vm_interrupt) and 
interrupt_function,
and switch the execute data and stack. The zend vm will execute the old online.

However, we will never see the resume() method returned and never get its 
return value.

> On 1 Nov 2017, at 17:14, Dmitry Stogov  wrote:
> 
> after zend_interrupt_function() callback VM continues execution using 
> EG(current_execute_data).
> callback may modify it in any way (e.g. unwind stack, or switch to another 
> co-routine or continuation).
> 
> Thanks. Dmitry.
> From: Haitao Lv 
> Sent: Wednesday, November 1, 2017 11:54:54 AM
> To: Dmitry Stogov
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] RFC - Zend VM Pause API 
>  
> It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
> only execute the interrupt_function and continue the current execution.
> 
> However, my RFC propose to stop the current execution.
> 
>> On 1 Nov 2017, at 16:07, Dmitry Stogov  wrote:
>> 
>> Hi,
>> 
>> It should be possible do similar things using EG(vm_interrupt) and 
>> zend_interrupt_function() callback (introduced in php-7.1)
>> ext/pcntl implements asynchronous signal handling using this.
>> 
>> Thanks. Dmitry.
>> From: Haitao Lv 
>> Sent: Wednesday, November 1, 2017 4:19:07 AM
>> To: PHP Internals
>> Subject: [PHP-DEV] RFC - Zend VM Pause API 
>>  
>> Hi, internals,
>> 
>> I propose to introduce a new zend vm pause api, and here is the RPF
>> 
>> https://wiki.php.net/rfc/zend-vm-pause-api
>> 
>> Please gave your comment.
>> 
>> Thank you.
>> 
>> 
>> 
>> -- 
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Zend VM Pause API

[Dmitry Stogov]

I'm not sure, why do you need to exit from the current VM instance.

It should be possible to perform fiber scheduling and VM context switch 
directly in interrupt handler (like in real OS).

VM should handle this out of the box (at least VM interrupts were designed with 
context switch in mind).


In your case, I suppose, part of zend_fiber_resume() should be merged into 
fiber_interrupt_function().

Also you should handle only your own interrupts (like ext/pcntl does checking 
PCNTL_G(pending_signals)).


Sorry, I don't have a lot of time to review your sources.

However, the implementation is really interesting, and I'm glad, someone is 
working on this.


Thanks. Dmitry.


From: Haitao Lv 
Sent: Wednesday, November 1, 2017 12:45:13 PM
To: Dmitry Stogov
Cc: PHP Internals
Subject: Re: [PHP-DEV] RFC - Zend VM Pause API

To make the discussion more detailed, please allow me to offer my 
implementation of use land coroutine(Fiber).

https://github.com/php/php-src/compare/master...fiberphp:fiber-ext?expand=1


> On 1 Nov 2017, at 17:32, Haitao Lv  wrote:
>
> Suppose we have a internal Coroutine class and it has a resume() method.
>
> In order to resume the coroutine, we have to call the resume() function.
>
> As the resume function is a internal method defined in c, we need call
>
> zend_execute_ex(backuped_execute_data)
>
> to resume the zend execution.
>
> If we need to pause the coroutine, we set the EG(vm_interrupt) and 
> interrupt_function,
> and switch the execute data and stack. The zend vm will execute the old 
> online.
>
> However, we will never see the resume() method returned and never get its 
> return value.
>
>> On 1 Nov 2017, at 17:14, Dmitry Stogov  wrote:
>>
>> after zend_interrupt_function() callback VM continues execution using 
>> EG(current_execute_data).
>> callback may modify it in any way (e.g. unwind stack, or switch to another 
>> co-routine or continuation).
>>
>> Thanks. Dmitry.
>> From: Haitao Lv 
>> Sent: Wednesday, November 1, 2017 11:54:54 AM
>> To: Dmitry Stogov
>> Cc: PHP Internals
>> Subject: Re: [PHP-DEV] RFC - Zend VM Pause API
>>
>> It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
>> only execute the interrupt_function and continue the current execution.
>>
>> However, my RFC propose to stop the current execution.
>>
>>> On 1 Nov 2017, at 16:07, Dmitry Stogov  wrote:
>>>
>>> Hi,
>>>
>>> It should be possible do similar things using EG(vm_interrupt) and 
>>> zend_interrupt_function() callback (introduced in php-7.1)
>>> ext/pcntl implements asynchronous signal handling using this.
>>>
>>> Thanks. Dmitry.
>>> From: Haitao Lv 
>>> Sent: Wednesday, November 1, 2017 4:19:07 AM
>>> To: PHP Internals
>>> Subject: [PHP-DEV] RFC - Zend VM Pause API
>>>
>>> Hi, internals,
>>>
>>> I propose to introduce a new zend vm pause api, and here is the RPF
>>>
>>> https://wiki.php.net/rfc/zend-vm-pause-api
>>>
>>> Please gave your comment.
>>>
>>> Thank you.
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] RFC - Zend VM Pause API

[Haitao Lv]

It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
only execute the interrupt_function and continue the current execution.

However, my RFC propose to stop the current execution.

> On 1 Nov 2017, at 16:07, Dmitry Stogov  wrote:
> 
> Hi,
> 
> It should be possible do similar things using EG(vm_interrupt) and 
> zend_interrupt_function() callback (introduced in php-7.1)
> ext/pcntl implements asynchronous signal handling using this.
> 
> Thanks. Dmitry.
> From: Haitao Lv 
> Sent: Wednesday, November 1, 2017 4:19:07 AM
> To: PHP Internals
> Subject: [PHP-DEV] RFC - Zend VM Pause API 
>  
> Hi, internals,
> 
> I propose to introduce a new zend vm pause api, and here is the RPF
> 
> https://wiki.php.net/rfc/zend-vm-pause-api 
> 
> 
> Please gave your comment.
> 
> Thank you.
> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php 
> 

Re: [PHP-DEV] RFC - Zend VM Pause API

[Haitao Lv]

Would it proper to introduce the following path?

diff --git a/Zend/zend_vm_def.h b/Zend/zend_vm_def.h
index 9bed9f86bb..cf0935df74 100644
--- a/Zend/zend_vm_def.h
+++ b/Zend/zend_vm_def.h
@@ -8920,13 +8920,19 @@ ZEND_VM_DEFINE_OP(137, ZEND_OP_DATA);

 ZEND_VM_HELPER(zend_interrupt_helper, ANY, ANY)
 {
+   int8_t interrupt_type = EG(vm_interrupt);
+
EG(vm_interrupt) = 0;
if (EG(timed_out)) {
zend_timeout(0);
} else if (zend_interrupt_function) {
SAVE_OPLINE();
zend_interrupt_function(execute_data);
-   ZEND_VM_ENTER();
+   if (interrupt_type == 2) {
+   ZEND_VM_RETURN();
+   } else {
+   ZEND_VM_ENTER();
+   }
}
ZEND_VM_CONTINUE();
 }

> On 1 Nov 2017, at 16:54, Haitao Lv  wrote:
> 
> It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
> only execute the interrupt_function and continue the current execution.
> 
> However, my RFC propose to stop the current execution.
> 
>> On 1 Nov 2017, at 16:07, Dmitry Stogov  wrote:
>> 
>> Hi,
>> 
>> It should be possible do similar things using EG(vm_interrupt) and 
>> zend_interrupt_function() callback (introduced in php-7.1)
>> ext/pcntl implements asynchronous signal handling using this.
>> 
>> Thanks. Dmitry.
>> From: Haitao Lv 
>> Sent: Wednesday, November 1, 2017 4:19:07 AM
>> To: PHP Internals
>> Subject: [PHP-DEV] RFC - Zend VM Pause API 
>> 
>> Hi, internals,
>> 
>> I propose to introduce a new zend vm pause api, and here is the RPF
>> 
>> https://wiki.php.net/rfc/zend-vm-pause-api 
>> 
>> 
>> Please gave your comment.
>> 
>> Thank you.
>> 
>> 
>> 
>> -- 
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php 
>> 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Zend VM Pause API

[Dmitry Stogov]

after zend_interrupt_function() callback VM continues execution using 
EG(current_execute_data).

callback may modify it in any way (e.g. unwind stack, or switch to another 
co-routine or continuation).


Thanks. Dmitry.


From: Haitao Lv 
Sent: Wednesday, November 1, 2017 11:54:54 AM
To: Dmitry Stogov
Cc: PHP Internals
Subject: Re: [PHP-DEV] RFC - Zend VM Pause API

It seems that set EG(vm_interrupt) to 1 could not stop the vm execution but 
only execute the interrupt_function and continue the current execution.

However, my RFC propose to stop the current execution.

On 1 Nov 2017, at 16:07, Dmitry Stogov 
> wrote:

Hi,

It should be possible do similar things using EG(vm_interrupt) and 
zend_interrupt_function() callback (introduced in php-7.1)
ext/pcntl implements asynchronous signal handling using this.

Thanks. Dmitry.

From: Haitao Lv >
Sent: Wednesday, November 1, 2017 4:19:07 AM
To: PHP Internals
Subject: [PHP-DEV] RFC - Zend VM Pause API

Hi, internals,

I propose to introduce a new zend vm pause api, and here is the RPF

https://wiki.php.net/rfc/zend-vm-pause-api

Please gave your comment.

Thank you.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Array Of for PHP 7

[Michael Morris]

Drupal 8 accomplishes this through assert() and a helper class.

function foo ( array $a ) {
  assert( Inspector::assertAllStrings( $a ));
}

This could be improved by having an collectionof operator similar to the
instanceof operator.

function ( array $a ) {
  assert( $a collectionof string );
}

I say "collectionof" because while arrays are the most common traversable
objects, they aren't the only ones.  The above approach, combined with the
existing assert structure, can provide the dev time checking of the code
while in under development, and it can be turned off in production. Or it
can be used outside of assert to be checked at all times.

Since this invokes a new keyword I think that would mean this solution
would be PHP 8.

Brackets might be used with instance of to notify it to traverse down one
level maybe??

function ( array $a ) {
  assert( $a instanceof [string] );
}

This avoids any BC issues, but it looks odd.  Not as odd as \ for a
namespace operation :P  But odd.


On Wed, Nov 1, 2017 at 10:40 AM, Rowan Collins 
wrote:

> On 31 October 2017 17:37:17 GMT+00:00, Levi Morrison 
> wrote:
> >  - Our current infrastructure requires us to check every element of
> >the array for conformance. While undesirable I believe this can be
> >optimized away in the future if we care enough, and therefore not a
> >show-stopper.
>
> Do you have a mechanism in mind for "optimising this away"? I think
> releasing the feature without any optimisation will just lead to painful
> slowdowns when people use it without realising the implications.
>
> As I said in my previous message, it seems to be a fundamental issue with
> PHP's current type declarations that they are a) runtime, and b) asserted
> at arbitrary points, not at assignment. So even if you optimise the check
> slightly, it's still a separate check every time you enter a new function,
> which puts a limit on optimisation.
>
> The only way I've thought of to improve things is to cache the result of
> previous type checks, but this comes with all the normal challenges of
> caching. For instance, all assignments into the array would need to
> invalidate these cached checks, or check the new value against each.
> References would be particularly tricky, as they were with the property
> type hint proposal.
>
> If we selectively invalidated cached checks, we'd be running specific type
> checks at every variable assignment, but not letting the user actually
> assert on those checks. At which point, should we approach from the other
> direction, and let the user declare variable types, rather than assert
> value types?
>
> This is kind of implied if we implement generics, too, since explicitly
> constructing an instance of list is asking the runtime to check future
> assignments to members of that list. In effect, could declaring "int $foo =
> 42;" be considered equivalent to "$foo = new checkedScalar(42);"?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Stanislav Malyshev]

Hi!

> From the body of the RFC:
> 
> "To enable for the closing marker to be indented, ... The indentation
> of the closing marker dictates the amount of whitespace to strip from
> each line within the heredoc/nowdoc"

Yes, that's what the RFC says. But the voting question only mentions
indenting the marker. I'd prefer voting options were clear and I didn't
have to second-guess the intent. It could be "Allow indenting the marker
and stripping the whitespace?" and all would be clear.

> "RFC voters - please read the RFC during the RFC period and ask
> questions then. ;-)" is an irritating way of writing this.

I've read the RFC, that is exactly why I was asking - because the voting
question did not match the text of the RFC, omitting rather serious side
effect.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Array Of for PHP 7

[Rowan Collins]

On 31 October 2017 17:37:17 GMT+00:00, Levi Morrison  wrote:
>  - Our current infrastructure requires us to check every element of
>the array for conformance. While undesirable I believe this can be
>optimized away in the future if we care enough, and therefore not a
>show-stopper.

Do you have a mechanism in mind for "optimising this away"? I think releasing 
the feature without any optimisation will just lead to painful slowdowns when 
people use it without realising the implications.

As I said in my previous message, it seems to be a fundamental issue with PHP's 
current type declarations that they are a) runtime, and b) asserted at 
arbitrary points, not at assignment. So even if you optimise the check 
slightly, it's still a separate check every time you enter a new function, 
which puts a limit on optimisation.

The only way I've thought of to improve things is to cache the result of 
previous type checks, but this comes with all the normal challenges of caching. 
For instance, all assignments into the array would need to invalidate these 
cached checks, or check the new value against each. References would be 
particularly tricky, as they were with the property type hint proposal.

If we selectively invalidated cached checks, we'd be running specific type 
checks at every variable assignment, but not letting the user actually assert 
on those checks. At which point, should we approach from the other direction, 
and let the user declare variable types, rather than assert value types? 

This is kind of implied if we implement generics, too, since explicitly 
constructing an instance of list is asking the runtime to check future 
assignments to members of that list. In effect, could declaring "int $foo = 
42;" be considered equivalent to "$foo = new checkedScalar(42);"?

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

[BohwaZ]

Sorry I thought the vote would automatically close, but apparently it
doesn't work like that. I was away from the internet so couldn't edit
the wiki page.

I can't find the place where we can see the voting history? Last time I
checked the page last week it was 6 to 5 or something like that.

On Mon, 30 Oct 2017 03:14:03 + / Dan Ackroyd
 said :

> The vote for this should have ended..3 days ago.
> 
> At which point I believe the vote was actually passing.
> 
> cheers
> Dan
> 
> On 9 October 2017 at 23:12, BohwaZ/PHP  wrote:
> > Kia ora,
> >
> > After some more discussions, I don't think we have much left to
> > discuss on that topic, so…
> >
> > Voting is now open for 2 weeks on this RFC:
> > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> >
> > Vote will end on Wednesday the 25th of October.
> >
> > Thanks to everyone who contributed to the discussion so far :)
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php