[PHP-DEV] Re: [RFC][Vote] Typed Properties

2016-05-20 Thread Tom Worster 

On 5/20/16 2:05 AM, Joe Watkins wrote:

Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.


I lack suffrage but I have a question about coercion and strictness.

When I assign a value to a property declared with scalar type, is it the 
strictness of the file containing the assignment that controls if 
coercion happens or not? And is the strictness of the file containing 
the declaration irrelevant?


I guess yes on both to be consistent with coercion on function 
invocation but I couldn't find this mentioned in the RFC.


Tom


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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

2016-05-20 Thread guilhermebla...@gmail.com 
Joe, I fixed a minor typo in the RFC, hope you didn't mind. =)

On Fri, May 20, 2016 at 5:25 AM, Lester Caine  wrote:

> On 20/05/16 07:05, Joe Watkins wrote:
> > Morning internals,
> >
> > Since we have our answer on nullable types, typed properties can now
> go
> > to vote.
> >
> > https://wiki.php.net/rfc/typed-properties#vote
> >
> > Note that, support for nullability as RFC'd will be merged when the
> > implementation for nullable_types is merged into master.
>
> I have just realised exactly why I have a problem with most of this ...
> Domain! Used as an 'OtherThing'
>
> This is ALSO attributes, since an SQL domain defines all of the
> attributes that I need to handle in relation to variables. 'int' on it's
> own does very little since one still needs to add all the other checks,
> but adding 'types' as a properly formatted domain solves all the
> problems I'm looking at ... and leaves plenty of room for others to
> abuse the in their own way?
>
>
> http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-domn.html
>
> Note such elements as [] to allow for arrays of a datatype
> although that still leaves the handling of mix arrays.
>
> Some of the conditions may seem irreverent, but if the domain is a set
> of keys for an array that logic then makes sense?
>
> I can even see the addition of a 'read only' flag to solve that problem
> while still constraining the initial setting of a domain.
>
> But this is simply user land code and does not need a small subset of
> elements of it added to the code base?
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Implement Generator::__invoke($value) as alias to Generator::send($value)

2016-05-20 Thread Niklas Keller 
2016-05-20 16:47 GMT+02:00 S.A.N :

> 2016-05-20 17:41 GMT+03:00 Niklas Keller :
> > 2016-05-20 15:34 GMT+02:00 S.A.N :
> >>
> >> Many interfaces work with callback functions, but they might work with
> >> the generators, if there was a method Generator::__invoke($value).
> >
> >
> > You can just use [$generator, "send"].
> >
>
> Yes, but it is slow and not nice :)
>

I agree, but this is a general issue, nothing special to generators.

Re: [PHP-DEV] Implement Generator::__invoke($value) as alias to Generator::send($value)

2016-05-20 Thread S.A.N 
2016-05-20 17:41 GMT+03:00 Niklas Keller :
> 2016-05-20 15:34 GMT+02:00 S.A.N :
>>
>> Many interfaces work with callback functions, but they might work with
>> the generators, if there was a method Generator::__invoke($value).
>
>
> You can just use [$generator, "send"].
>

Yes, but it is slow and not nice :)

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

Re: [PHP-DEV] Implement Generator::__invoke($value) as alias to Generator::send($value)

2016-05-20 Thread Niklas Keller 
2016-05-20 15:34 GMT+02:00 S.A.N :

> Many interfaces work with callback functions, but they might work with
> the generators, if there was a method Generator::__invoke($value).


You can just use [$generator, "send"].

[PHP-DEV] Re: "finally" handling refactoring (Bug #72213)

2016-05-20 Thread Nikita Popov 
On Fri, May 20, 2016 at 2:07 PM, Dmitry Stogov  wrote:

> hi,
>
>
> Please review the path
> https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330
>
>
> I hope, it should completely fix https://bugs.php.net/bug.php?id=72213
>
>
> I'm going to commit this on Monday.
>
>
> Thanks. Dmitry.
>
>From a quick look:

https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L74
=> should this be orig_try_catch_offset?

https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L303
=> This assumes that either there's a catch block or a finally block to go
to. However, if we're in the catch block of a try/catch (without finally)
that may not be true.

Also, this still leaks one exception :(

[PHP-DEV] Implement Generator::__invoke($value) as alias to Generator::send($value)

2016-05-20 Thread S.A.N 
Many interfaces work with callback functions, but they might work with
the generators, if there was a method Generator::__invoke($value).

I apologize if this topic has been discussed.
Thank.

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

[PHP-DEV] Re: "finally" handling refactoring (Bug #72213)

2016-05-20 Thread Nikita Popov 
On Fri, May 20, 2016 at 2:07 PM, Dmitry Stogov  wrote:

> hi,
>
>
> Please review the path
> https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330
>
>
> I hope, it should completely fix https://bugs.php.net/bug.php?id=72213
>
>
> I'm going to commit this on Monday.
>
>
> Thanks. Dmitry.
>
USE_ZEND_ALLOC=0 valgrind sapi/cli/php Zend/tests/bug65784.php

gives me

==27339== Invalid read of size 8
==27339==at 0xB93F76: ZEND_CATCH_SPEC_CONST_CV_HANDLER
(zend_vm_execute.h:9362)
==27339==by 0xB7E872: execute_ex (zend_vm_execute.h:426)
==27339==by 0xB7EA74: zend_execute (zend_vm_execute.h:471)
==27339==by 0xB161EA: zend_execute_scripts (zend.c:1427)
==27339==by 0xA5319D: php_execute_script (main.c:2492)
==27339==by 0xC058D5: do_cli (php_cli.c:982)
==27339==by 0xC06D65: main (php_cli.c:1352)
==27339==  Address 0xf5e0880 is 16 bytes inside a block of size 152 free'd
==27339==at 0x4C2BDEC: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27339==by 0xAD5B2C: _efree (zend_alloc.c:2423)
==27339==by 0xB6C4A6: zend_objects_store_del (zend_objects_API.c:187)
==27339==by 0xB10FF6: _zval_dtor_func (zend_variables.c:56)
==27339==by 0xB6445E: i_zval_ptr_dtor (zend_variables.h:48)
==27339==by 0xB64636: zend_object_std_dtor (zend_objects.c:68)
==27339==by 0xB6C38D: zend_objects_store_del (zend_objects_API.c:178)
==27339==by 0xB10FF6: _zval_dtor_func (zend_variables.c:56)
==27339==by 0xB7BF6E: i_free_compiled_variables (zend_execute.c:2101)
==27339==by 0xB7EABD: zend_leave_helper_SPEC (zend_vm_execute.h:481)
==27339==by 0xB83F83: ZEND_FAST_RET_SPEC_HANDLER
(zend_vm_execute.h:1894)
==27339==by 0xB7E872: execute_ex (zend_vm_execute.h:426)

and so on.

Nikita

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-05-20

2016-05-20 Thread lp_benchmark_robot 
Results for project PHP master, build date 2016-05-20 06:29:09+03:00
commit: 4f077ae
previous commit:88196e9
revision date:  2016-05-20 01:51:05+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.26% -0.67%  0.49%  
  7.31%
:-)   Drupal 7.36 cgi -T1  0.11%  4.62%  4.85%  
  5.38%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.19%  0.41%  
  3.65%
:-|   bench.php cgi -T100  0.03% -0.91% 27.66%  
 -2.19%
:-|  micro_bench.php cgi -T10  0.07%  0.54%  5.12%  
  2.48%
:-(  mandelbrot.php cgi -T100  0.72% -1.49% 30.17%  
  7.18%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/ugly-benchmark-results-for-php-master-2016-05-20/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] "finally" handling refactoring (Bug #72213)

2016-05-20 Thread Derick Rethans 
On Fri, 20 May 2016, Dmitry Stogov wrote:

> Please review the path 
> https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330

https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L194-L196
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L356-L358

Why are you switching these around?

https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L500-L501
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330#file-bug72213-diff-L511-L512

You should probably remove them instead of commenting them out.

And Nikita, does this fix my issues with trying to walk through the 
possible paths and branches with Xdebug?

> 
> I hope, it should completely fix https://bugs.php.net/bug.php?id=72213
> 
> 
> I'm going to commit this on Monday.

To which branches?

cheers,
Derick

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

[PHP-DEV] "finally" handling refactoring (Bug #72213)

2016-05-20 Thread Dmitry Stogov 
hi,


Please review the path 
https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330


I hope, it should completely fix https://bugs.php.net/bug.php?id=72213


I'm going to commit this on Monday.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

2016-05-20 Thread Lester Caine 
On 20/05/16 07:05, Joe Watkins wrote:
> Morning internals,
> 
> Since we have our answer on nullable types, typed properties can now go
> to vote.
> 
> https://wiki.php.net/rfc/typed-properties#vote
> 
> Note that, support for nullability as RFC'd will be merged when the
> implementation for nullable_types is merged into master.

I have just realised exactly why I have a problem with most of this ...
Domain! Used as an 'OtherThing'

This is ALSO attributes, since an SQL domain defines all of the
attributes that I need to handle in relation to variables. 'int' on it's
own does very little since one still needs to add all the other checks,
but adding 'types' as a properly formatted domain solves all the
problems I'm looking at ... and leaves plenty of room for others to
abuse the in their own way?

http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-domn.html

Note such elements as [] to allow for arrays of a datatype
although that still leaves the handling of mix arrays.

Some of the conditions may seem irreverent, but if the domain is a set
of keys for an array that logic then makes sense?

I can even see the addition of a 'read only' flag to solve that problem
while still constraining the initial setting of a domain.

But this is simply user land code and does not need a small subset of
elements of it added to the code base?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Exception::getLine()

2016-05-20 Thread Rowan Collins 

On 20/05/2016 08:22, Niklas Keller wrote:

2016-05-20 4:13 GMT+02:00 Jesse Schalken :

The top frame is the construction (get_error) and the site of the throw
(do_throw) doesn't appear in the stack at all.



The comparison with JavaScript isn't a good one, since you can throw
everything in JS. If they didn't provide the stack trace upon throw, you
would not have a stack trace at all if you throw a plain string.




That explanation justifies completely the opposite behaviour to what 
Jesse described.


According to MDN [1] the "stack" property is completley unstandardised, 
and some engines may indeed populate it on throw, but there's no hint on 
that page that they'll attach it to anything not constructed as an Error.


So it's not a great comparison for either side (note that it was 
originally brought up by Rasmus as an example where it *does* come from 
the throw site) because the language doesn't actually guarantee you a 
stack trace at all.


[1] 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack


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] Typed Properties

2016-05-20 Thread Larry Garfield 

On 05/20/2016 08:05 AM, Joe Watkins wrote:

Morning internals,

 Since we have our answer on nullable types, typed properties can now go
to vote.

 https://wiki.php.net/rfc/typed-properties#vote

 Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

 Please participate.

Cheers
Joe


I don't get a vote, but I will say "endorse!"

--Larry Garfield

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

Re: [PHP-DEV] [RFC][VOTE] Nullable Types

2016-05-20 Thread Pascal MARTIN, AFUP 

Le 10/05/2016 à 17:22, Levi Morrison a écrit :

Dmitry and I have opened [voting on Nullable Types][1].
   [1]: https://wiki.php.net/rfc/nullable_types#voting_choices

Hi,

At AFUP, we would be +1 for having nullable types, for both parameters 
and return values.


It often seems, with PHP 7.0, this specific feature is missing ;-)
A few indicated "int?" would have seemed more familiar than "?int", but 
it doesn't seem like a deal-breaker; and being close to Hack is more 
important than being close to - say - C#.
In our discussions, more (not a big margin though) were +1 for nullable 
types on parameters than on return values; no deal-breaker here either.


Anyway, happy to see votes are going well and nullables types are more 
than likely coming for PHP 7.1!


Thanks for you work on this!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

Re: [PHP-DEV] Exception::getLine()

2016-05-20 Thread Niklas Keller 
2016-05-20 4:13 GMT+02:00 Jesse Schalken :

>
> On Fri, May 20, 2016 at 4:35 AM, Rasmus Schultz 
> wrote:
>
>> This is inconsistent with at least JavaScript and C#, where the stack
>> trace is populated at the throw site. (Probably others?)
>>
>
> I'm not sure about C#, but in JavaScript (Node.js):
>
> function get_error() {
> return new Error('my error');
> }
>
> function do_throw(e) {
> throw e;
> }
>
> try {
> do_throw(get_error());
> } catch (e) {
> console.log(e.stack);
> }
>
>
> results in:
>
> Error: my error
> at get_error (/home/jesse/src/test.js:2:12)
> at Object. (/home/jesse/src/test.js:10:14)
> at Module._compile (module.js:413:34)
> at Object.Module._extensions..js (module.js:422:10)
> at Module.load (module.js:357:32)
> at Function.Module._load (module.js:314:12)
> at Function.Module.runMain (module.js:447:10)
> at startup (node.js:146:18)
> at node.js:404:3
>
>
> The top frame is the construction (get_error) and the site of the throw
> (do_throw) doesn't appear in the stack at all.
>

The comparison with JavaScript isn't a good one, since you can throw
everything in JS. If they didn't provide the stack trace upon throw, you
would not have a stack trace at all if you throw a plain string.

[PHP-DEV] [RFC][Vote] Typed Properties

2016-05-20 Thread Joe Watkins 
Morning internals,

Since we have our answer on nullable types, typed properties can now go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe