Re: [PHP-DEV] [VOTE][RESULTS] 7.1 RMs selection

[Davey Shafik]

Hey all,

As Joe said, thanks for voting, and we have lots of work ahead of us to
make sure that 7.1 is a solid release — I'll do my best to ensure that
happens!

- Davey

On Tue, May 3, 2016 at 10:01 PM, Joe Watkins  wrote:

> Morning internals,
>
> Thanks for voting :)
>
> Let the work commence ...
>
> Cheers
> Joe
>
> On Tue, May 3, 2016 at 11:03 PM, Larry Garfield 
> wrote:
>
> > On 05/03/2016 04:36 PM, Anatol Belski wrote:
> >
> >> Hi,
> >>
> >> The poll under https://wiki.php.net/todo/php71 is closed. Thanks
> everyone
> >> voted.
> >>
> >> The elected 7.1 release managers are Davey Shafik and Joe Watkins.
> >> Congrats
> >> and godspeed, guys!
> >>
> >> Regards
> >>
> >> Anatol
> >>
> >
> > Congratudolences, Davey and Joe!
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[S.A.N]

> I don't think we should wait, I was just thinking that it might not be ready
> until that time.
>
> Also, if we plan on rewriting streams and I/O to all be async and use libuv
> underneath, that would probably be a BC break unless the existing functions
> just become blocking interfaces for a separate async API. If it was a large
> BC break, it probably would need to wait for PHP 8.
>
> Now that I think about it, that would be our chance to replace stream
> resources with classes...
>
> $file = \php\stream::open("file.txt");
> $bytes = await $file->read(1024);
> $file->close();
>
> Then rewrite fread() and friends to be aliases that block instead of await
> results.

This is a great opportunity to normalize API standard libraries PHP :)

> $bytes = await $file->read(1024);

It is rarely necessary, more often needs

$result = await $db->query($sql);
and
$result = await $noSql->get($key);

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

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[Stephen Coakley]

On 05/04/2016 11:44 AM, Niklas Keller wrote:

2016-05-04 16:40 GMT+02:00 Stephen Coakley :
Why do we have to wait until PHP 8? Should be mostly backwards compatible
and be fine in 7.2 or so. Issue is probably more deciding on an API.



I don't think we should wait, I was just thinking that it might not be 
ready until that time.


Also, if we plan on rewriting streams and I/O to all be async and use 
libuv underneath, that would probably be a BC break unless the existing 
functions just become blocking interfaces for a separate async API. If 
it was a large BC break, it probably would need to wait for PHP 8.


Now that I think about it, that would be our chance to replace stream 
resources with classes...


$file = \php\stream::open("file.txt");
$bytes = await $file->read(1024);
$file->close();

Then rewrite fread() and friends to be aliases that block instead of 
await results.


--
Stephen

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

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[S.A.N]

>> /Legend speaks of such plans, but they come and go in whispers. Like a
>> shadow, or a mist from the east. The prophecy spake of such features
>> targeting PHP8; lo, most believe it to be myth./
>
>
> Why do we have to wait until PHP 8? Should be mostly backwards compatible
> and be fine in 7.2 or so. Issue is probably more deciding on an API.
>
>

Yes, I think so, too, do not need to wait for version 8, can start
7.1-2 possible even as another SAPI.

P.S.
These works will accelerate 5x-10x
https://gnugat.github.io/2016/04/13/super-speed-sf-react-php.html

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

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[Niklas Keller]

2016-05-04 16:40 GMT+02:00 Stephen Coakley :

> On 05/04/2016 05:59 AM, S.A.N wrote:
>
>> EventLoop interface, on development stage:
>> https://github.com/async-interop/event-loop
>>
>
> That's a userland design for event loops; async/await and coroutines don't
> necessarily depend on an event loop. They could be added to the language
> without an event loop, and simply require the user to provide the event
> loop.
>

Would be strange to have async / await in the language without an event
loop, but it's possible, yes.


> My idea was to make a transition into async as simple as possible.
>
> Also, I'm partially responsible for the event loop interface above. :P
>
> PHP wrappers for libev and libeio supported PHP 7.
>> https://pecl.php.net/package/ev
>> https://pecl.php.net/package/eio
>>
> >
>
>> libuv - certainly better because it has everything you need and a huge
>> community.
>>
>
> I agree; libuv is probably the best of the bunch, if we include an event
> loop library in future versions of PHP. It is not necessary to have a PHP
> wrapper for libuv, since if it was included in the interpreter itself we
> would be just using the C interface.
>
> Very need async/await in the PHP core (based on generators).
>> Perhaps there are plans in core developers, for implement async/await?
>>
>
> /Legend speaks of such plans, but they come and go in whispers. Like a
> shadow, or a mist from the east. The prophecy spake of such features
> targeting PHP8; lo, most believe it to be myth./


Why do we have to wait until PHP 8? Should be mostly backwards compatible
and be fine in 7.2 or so. Issue is probably more deciding on an API.


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

[PHP-DEV] The death of `#ifndef FAST_ZPP`?

[Andrea Faulds]

Hi everyone,

You may recall that PHP 7.0 introduced a new API for processing 
arguments to internal functions, the "Fast Parameter Parsing API" or 
FAST_ZPP (https://wiki.php.net/rfc/fast_zpp), which is an alternative to 
the existing zend_parse_parameters function family.


Since FAST_ZPP was implemented, many functions in built-in PHP 
extensions look like this:


#ifndef FAST_ZPP
	if (zend_parse_parameters(ZEND_NUM_ARGS(), "S|S", , ) == 
FAILURE) {

return;
}
#else
ZEND_PARSE_PARAMETERS_START(1, 2)
Z_PARAM_STR(str)
Z_PARAM_OPTIONAL
Z_PARAM_STR(what)
ZEND_PARSE_PARAMETERS_END();
#endif

That is, they have /two/ sets of parameter processing code: one using 
the old API, and one using the new API, with conditional compilation. 
This is necessary because it is still possible to turn off FAST_ZPP by 
changing the value of the macro.


However, should that be the case? The FAST_ZPP RFC was approved and PHP 
7.0 was released containing it enabled by default, so it's no longer 
just an experimental performance enhancement. Furthermore, I have no 
reason to believe that the option to turn off FAST_ZPP is actually used 
in practice, though feel free to prove me wrong!


Requiring all usages of FAST_ZPP to be accompanied by a 
zend_parse_parameters() fallback creates code bloat. It also creates 
hidden, potentially build-breaking bugs, because the code is rarely 
built with FAST_ZPP disabled. It's like the old TSRMLS_CC situation.


Furthermore, for those who would prefer the FAST_ZPP API, it is 
inconvenient that they cannot use it exclusively and must also use 
zend_parse_parameters(), doubling the effort.


So, I would like to ask: would there be any objections to going through 
and removing all unnecessary zend_parse_parameters fallbacks, and making 
it impossible to disable FAST_ZPP? This would make the two APIs equally 
valid.


Thanks!

--
Andrea Faulds
https://ajf.me/

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

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-05-04

[lp_benchmark_robot]

Results for project PHP master, build date 2016-05-04 11:14:20+03:00
commit: ee55110
previous commit:153b27d
revision date:  2016-05-03 19:11:15+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.17%  0.32%  0.67%  
  7.17%
:-|   Drupal 7.36 cgi -T1  0.18%  0.58%  0.27%  
  4.48%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11%  0.29%  0.67%  
  3.01%
:-|   bench.php cgi -T100  0.12% -0.45% 25.00%  
  1.95%
:-(  micro_bench.php cgi -T10  0.02% -3.84%  1.71%  
  5.96%
:-(  mandelbrot.php cgi -T100  0.22% -1.86% 31.30%  
  2.91%
---
* Relative Standard Deviation (Standard Deviation/Average)

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

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] Re: async/await - is future reserved words in PHP 7.x?

[Stephen Coakley]

On 05/04/2016 05:59 AM, S.A.N wrote:

EventLoop interface, on development stage:
https://github.com/async-interop/event-loop


That's a userland design for event loops; async/await and coroutines 
don't necessarily depend on an event loop. They could be added to the 
language without an event loop, and simply require the user to provide 
the event loop.


My idea was to make a transition into async as simple as possible.

Also, I'm partially responsible for the event loop interface above. :P


PHP wrappers for libev and libeio supported PHP 7.
https://pecl.php.net/package/ev
https://pecl.php.net/package/eio

>

libuv - certainly better because it has everything you need and a huge
community.


I agree; libuv is probably the best of the bunch, if we include an event 
loop library in future versions of PHP. It is not necessary to have a 
PHP wrapper for libuv, since if it was included in the interpreter 
itself we would be just using the C interface.



Very need async/await in the PHP core (based on generators).
Perhaps there are plans in core developers, for implement async/await?


/Legend speaks of such plans, but they come and go in whispers. Like a 
shadow, or a mist from the east. The prophecy spake of such features 
targeting PHP8; lo, most believe it to be myth./


--
Stephen

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

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Jesse Schalken]

On 4 May 2016 10:41 pm, "Rowan Collins"  wrote:
>
>
> You could either think of this as "setting lots of variables":
>
> new Foo { $bar = 1, $baz = 2 }
>
> or you could think of it as "an object literal like an array literal":
>
> new Foo { 'bar' => 1, 'baz' => 2 }
>

I think a $ is only necessary to disambiguate, ie between variable and
constant. It isn't necessary as a prefix for properties when it is
unambiguous that the thing is a property. Eg property access is ->foo, not
->$foo.

I don't think the string literal syntax is appropriate for
classes/structs/records which have a defined, static structure. You would
use that when you're talking about a hash table/associative array/map/dict,
for which the key is often an arbitrary expression.

So I would go with plain property name without prefix. It certainly looks
nicer in the context of annotations.

>
> And then we also need to think about sitting nicely with anonymous class
syntax. Not to mention Joe's proposal for lexical scope:
https://wiki.php.net/rfc/lexical-anon
>

AFAIK anonymous classes always start with "new class ..", so there would be
no ambiguity. It would be an optional {...} part that follows a class
instantiation, anonymous or not.

>
> For the record, I like the idea, if we can come up with a consistent plan
for how these pieces of syntax will work together, and not paint ourselves
into an ASCII-art hole...
>

It sounds like this conversation has been had before (but I'm not sure
about instantiate-and-set-properties specifically), but nonetheless the
problem remains and it's a common pain point for me and fellow devs.
Annotations sound like the ideal time to address it since they also need to
instantiate classes and set public properties in one expression.

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Rowan Collins]

Jesse Schalken wrote on 04/05/2016 13:20:

(maybe there should be a $ before the property names, not sure)


And there's the rub! :P

When named parameters have been discussed before, there was a lot of 
bikeshedding over what the syntax should look like, and this is arguably 
a very similar feature.


You could either think of this as "setting lots of variables":

new Foo { $bar = 1, $baz = 2 }

or you could think of it as "an object literal like an array literal":

new Foo { 'bar' => 1, 'baz' => 2 }


And then we also need to think about sitting nicely with anonymous class 
syntax. Not to mention Joe's proposal for lexical scope: 
https://wiki.php.net/rfc/lexical-anon



For the record, I like the idea, if we can come up with a consistent 
plan for how these pieces of syntax will work together, and not paint 
ourselves into an ASCII-art hole...


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

[Jesse Schalken]

On Sat, Apr 30, 2016 at 9:47 AM, Larry Garfield 
wrote:

> 3) Some way to provide a data definition for the annotation that can be
> checked at compile time.  This could be classes, a la Doctrine. It could be
> a new Annotation type as others have suggested.  It could be something
> else, akin to a struct like Liz Smith keeps toying with.  I'm flexible
> here.  But some way to provide a data definition for the annotation that is
> more robust than "you get an AST for an associative array that you can eval
> to an array yourself, good luck" is, I believe, mandatory for these to be
> successful for more than the most trivial use cases.  If that data
> definition is a class or class-like type, that also resolves the namespace
> question very easily.
>
>
I would love it if annotations were just classes with public properties,
and the annotation shorthand for instantiating and setting properties was
generally avaliable. At the moment if you wish to instantiate an object and
set some public properties, you have to use a temporary variable

$album = new Album();

$album->name = "Albumius";
$album->artist = "Artistus";

$album->year = 2013;

return $album;


or define setters for all the properties so you can chain them

return (new Album())

->setName("Albumius")

->setArtist("Artistus")

->setYear(2013);


or forego the benefits of classes and use an array

return [
'name' => "Albumius",
'artist' => "Artistus",
'year' => 2013,
];


C# has an "instantiate-and-set-properties" shorthand like this, which would
be great to have in PHP:

return new Album() {
name = "Albumius",
artist = "Artistus",
year = 2013,
};


and if you drop the "new" (and constructor parens are already optional)
you've got a pretty good annotation syntax right there.

<>

<>

<>


So the annotation syntax could just be class instantiation without the
"new".

(maybe there should be a $ before the property names, not sure)

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

[S.A.N]

> I think we can spoonfeed the massive undertaking a bit by spreading it
> across several iterations just to get things going. An idea I had was to
> just begin by providing coroutines as part of the language. That would
> include a `\Coroutine` class, as well as await / async keywords. This would
> at least enable third party async libraries to be more compatible since they
> would have the same await types and semantics.
>
> The next step (or at the same time as the first) is to provide some sort of
> `\EventLoopInterface` along with
>
> \EventLoop::getLoop(): \EventLoopInterface
> \EventLoop::setLoop(\EventLoopInterface)
> \EventLoop::run()
> \EventLoop::stop()
> \EventLoop::tick()
>
> To start out, just provide the internal coroutine scheduler as a default
> implementation. Coroutines would use the "event loop" to schedule resumes.
>
> Doing so would allow even more interoperability if a library chose to
> implement `\EventLoopInterface` in its event loop, where it handles
> coroutine scheduling (or lets it fall back to the internal one), and could
> also provide I/O "extras".
>
> The final step would be to bring libuv into PHP, itself as a better default
> implementation of `\EventLoopInterface`.
>
EventLoop interface, on development stage:
https://github.com/async-interop/event-loop

PHP wrappers for libev and libeio supported PHP 7.
https://pecl.php.net/package/ev
https://pecl.php.net/package/eio

libuv - certainly better because it has everything you need and a huge
community.

Very need async/await in the PHP core (based on generators).
Perhaps there are plans in core developers, for implement async/await?

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

Re: [PHP-DEV] zend_pass_function/zif_pass

[Derick Rethans]

On Wed, 4 May 2016, Dmitry Stogov wrote:

> I don't see a big problem exporting zif_pass, if this's really necessary.

Bob already committed that, and I've a PR for Xdebug too:
https://github.com/xdebug/xdebug/pull/271/commits/c4a539d75f0d2546e9d0cb0dbc06f5a7a31f447e

cheers,
Derick

> 
> From: Nikita Popov 
> Sent: Saturday, April 30, 2016 8:40:54 PM
> To: Derick Rethans
> Cc: Dmitry Stogov; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] zend_pass_function/zif_pass
> 
> On Sat, Apr 30, 2016 at 7:12 PM, Derick Rethans 
> > wrote:
> Hi!
> 
> I'm trying to make Xdebug up to date with master again, and after fixing
> the static changes that Dmitry highlighted, I am still baffled by
> something else.
> 
> My function traces now have an extra entry for each constructor - even
> for classes that have no constructor, such as stdClass.
> 
> Code
> 
>  $tf = xdebug_start_trace(sys_get_temp_dir() . '/'. uniqid('xdt', TRUE));
> 
> $a = new StdClass;
> 
> xdebug_stop_trace();
> echo file_get_contents($tf);
> ?>
> 
> In PHP 7.1 (master) this generates:
> 
>=> $tf = '/tmp/xdt5724dfa31b3050.51884776.xt' 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
> 0.0017 386376 -> {main}() 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:0
>=> $a = class stdClass {  } 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
> 0.0017 386472 -> xdebug_stop_trace() 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
> 0.0018 386568
> 
> Where as in PHP 5.6 and 7.0, it generates:
> 
> TRACE START [2016-04-30 17:10:19]
>=> $tf = '/tmp/xdt5724e6fb674b31.38510038.xt' 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
>=> $a = class stdClass {  } 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
> 0.0006 274008 -> xdebug_stop_trace() 
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
> 0.0006 274128
> TRACE END   [2016-04-30 17:10:19]
> 
> The master version has the extra {main}, which comes from an additional
> call to zend_execute_internal.
> 
> When looking into this, I see that that extra frame is a handle
> zend_pass_function / zif_pass. How has this changed recently, and more
> importantly, how can I detect this? I can't do "edata.func ==
> zend_pass_function" as neither zend_pass_function or zif_pass are
> exported symbols.
> 
> Any hints on how to handle this?
> 
> cheers,
> Derick
> 
> Hey Derick!
> 
> This change is due to http://www.serverphorums.com/read.php?7,1439618,1439618 
> / 
> https://github.com/php/php-src/commit/8e5b139732893d2a5f6ba3ae0a0b2b5cf6dba09f.
> 
> I don't see a good way for you to handle this as things stand now. I think we 
> should export the zend_pass_function symbol.
> 
> Nikita
> 

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

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

Re: [PHP-DEV] [RFC] Pipe Operator

[Jesse Schalken]

On Sun, May 1, 2016 at 4:05 AM, Larry Garfield 
wrote:

>
> In a way... Sara, this syntax feels like it's only one step removed from
> promises; if any of the chained steps involve IO, it becomes basically what
> promises are for.  Am I barking down the wrong tree, or is there something
> we could connect there?  (I don't mean "reject this in favor of promises",
> but more "is there something we can do here to be forward thinking, since
> lots of people want to see async in core PHP?")
>
>
If you had async/await, you could of course use |> to chain async
operations in an async function by using "await $$" in place of "$$" (since
$$ would be the Promise/Awaitable):

$ret = scandir_async($arg)
   |> array_filter(await $$, ...)
   |> ...


That's quite neat, IMO, and the features are still orthogonal.

You could introduce a new operator to combine the "|>" and "await", say
"a|>", but to add an operator just to combine two others would seem a bit
arbitrary.

You could also generalise |> as a monadic bind (with Promise as the monad
for asynchronicity) but I don't know how that would fit in PHP land without
a meaningful way to turn an expression into a closure. It could be added
later as something like "|>>" if need be.

Re: [PHP-DEV] zend_pass_function/zif_pass

[Joe Watkins]

Morning Dmitry,

Bob already exported it.


http://git.php.net/?p=php-src.git;a=commit;h=f59de7ea368da55f1f21ca82810febb3cdec06f0

Cheers
Joe

On Wed, May 4, 2016 at 7:28 AM, Dmitry Stogov  wrote:

> I don't see a big problem exporting zif_pass, if this's really necessary.
>
>
> Thanks. Dmitry.
>
> 
> From: Nikita Popov 
> Sent: Saturday, April 30, 2016 8:40:54 PM
> To: Derick Rethans
> Cc: Dmitry Stogov; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] zend_pass_function/zif_pass
>
> On Sat, Apr 30, 2016 at 7:12 PM, Derick Rethans > wrote:
> Hi!
>
> I'm trying to make Xdebug up to date with master again, and after fixing
> the static changes that Dmitry highlighted, I am still baffled by
> something else.
>
> My function traces now have an extra entry for each constructor - even
> for classes that have no constructor, such as stdClass.
>
> Code
>
>  $tf = xdebug_start_trace(sys_get_temp_dir() . '/'. uniqid('xdt', TRUE));
>
> $a = new StdClass;
>
> xdebug_stop_trace();
> echo file_get_contents($tf);
> ?>
>
> In PHP 7.1 (master) this generates:
>
>=> $tf = '/tmp/xdt5724dfa31b3050.51884776.xt'
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
> 0.0017 386376 -> {main}()
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:0
>=> $a = class stdClass {  }
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
> 0.0017 386472 -> xdebug_stop_trace()
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
> 0.0018 386568
>
> Where as in PHP 5.6 and 7.0, it generates:
>
> TRACE START [2016-04-30 17:10:19]
>=> $tf = '/tmp/xdt5724e6fb674b31.38510038.xt'
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
>=> $a = class stdClass {  }
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
> 0.0006 274008 -> xdebug_stop_trace()
> /home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
> 0.0006 274128
> TRACE END   [2016-04-30 17:10:19]
>
> The master version has the extra {main}, which comes from an additional
> call to zend_execute_internal.
>
> When looking into this, I see that that extra frame is a handle
> zend_pass_function / zif_pass. How has this changed recently, and more
> importantly, how can I detect this? I can't do "edata.func ==
> zend_pass_function" as neither zend_pass_function or zif_pass are
> exported symbols.
>
> Any hints on how to handle this?
>
> cheers,
> Derick
>
> Hey Derick!
>
> This change is due to
> http://www.serverphorums.com/read.php?7,1439618,1439618 /
> https://github.com/php/php-src/commit/8e5b139732893d2a5f6ba3ae0a0b2b5cf6dba09f
> .
>
> I don't see a good way for you to handle this as things stand now. I think
> we should export the zend_pass_function symbol.
>
> Nikita
>

Re: Fwd: [PHP-DEV] [RFC] PHP Attributes

[Yasuo Ohgaki]

Hi Fleshgrinder

On Fri, Apr 29, 2016 at 4:42 AM, Fleshgrinder  wrote:
> Is there a reason why you think that Design by Contract (DbC) should be
> implemented via annotations/attributes?

It's not complement of DbC, although it could be used.

Basic DbC idea is "Do validations always and fully during development
but disable almost all validations for production".

There are separated RFC for DbC
https://wiki.php.net/rfc/introduce_design_by_contract
https://wiki.php.net/rfc/dbc
https://wiki.php.net/rfc/dbc2

I like you version of syntax, but above syntax is the result of DbC
discussion so far.
I would like to reactivate DbC discussion soon...

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] zend_pass_function/zif_pass

[Dmitry Stogov]

I don't see a big problem exporting zif_pass, if this's really necessary.


Thanks. Dmitry.


From: Nikita Popov 
Sent: Saturday, April 30, 2016 8:40:54 PM
To: Derick Rethans
Cc: Dmitry Stogov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] zend_pass_function/zif_pass

On Sat, Apr 30, 2016 at 7:12 PM, Derick Rethans 
> wrote:
Hi!

I'm trying to make Xdebug up to date with master again, and after fixing
the static changes that Dmitry highlighted, I am still baffled by
something else.

My function traces now have an extra entry for each constructor - even
for classes that have no constructor, such as stdClass.

Code



In PHP 7.1 (master) this generates:

   => $tf = '/tmp/xdt5724dfa31b3050.51884776.xt' 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
0.0017 386376 -> {main}() 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:0
   => $a = class stdClass {  } 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
0.0017 386472 -> xdebug_stop_trace() 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
0.0018 386568

Where as in PHP 5.6 and 7.0, it generates:

TRACE START [2016-04-30 17:10:19]
   => $tf = '/tmp/xdt5724e6fb674b31.38510038.xt' 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:2
   => $a = class stdClass {  } 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:4
0.0006 274008 -> xdebug_stop_trace() 
/home/derick/dev/php/derickr-xdebug/tests/assignment-trace11.php:6
0.0006 274128
TRACE END   [2016-04-30 17:10:19]

The master version has the extra {main}, which comes from an additional
call to zend_execute_internal.

When looking into this, I see that that extra frame is a handle
zend_pass_function / zif_pass. How has this changed recently, and more
importantly, how can I detect this? I can't do "edata.func ==
zend_pass_function" as neither zend_pass_function or zif_pass are
exported symbols.

Any hints on how to handle this?

cheers,
Derick

Hey Derick!

This change is due to http://www.serverphorums.com/read.php?7,1439618,1439618 / 
https://github.com/php/php-src/commit/8e5b139732893d2a5f6ba3ae0a0b2b5cf6dba09f.

I don't see a good way for you to handle this as things stand now. I think we 
should export the zend_pass_function symbol.

Nikita