Re: [PHP-DEV] reused hash tables in large data structures in PHP7

[Xinchen Hui]

Hey:

On Tue, May 17, 2016 at 6:00 AM, Adam Baratz  wrote:

> Hi,
>
> I've encountered a hard-to-consistently-reproduce issue with HashTable
> zvals. I have code that will generate big nested \stdClass structures for
> JSON encoding. It does so using classes that have methods that generate
> those fields. For example, you could have a class like this:
>
> class Block {
>   public function css_classes() {
> return ['x', 'y', 'z'];
>   }
> }
>
> Other code would translate it into a value that would var_dump() as this:
>
> object(stdClass)#1 (1) {
>   ["css_classes"]=>
>   array(3) {
> [0]=>
> string(1) "x"
> [1]=>
> string(1) "y"
> [2]=>
> string(1) "z"
>   }
> }
>
> The template data could include multiple instances of Block. As in, a
> \stdClass could be generated with multiple copies of that array content.
> That data could get sent to json_encode(), which
> uses ZEND_HASH_APPLY_PROTECTION/etc. to avoid recursion. I've seen
> situations where that array of strings triggers that recursion check. But
>
the array might be stored in shared memory(immutable array), in this case,
you should not edit the apply count ,

you should check it,  like what json does:

https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L156


thanks

it's not always, and a php-fpm restart can make it go away.
>
> Can anyone think of why this might happen?
>
> Thanks,
> Adam
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] reused hash tables in large data structures in PHP7

[Adam Baratz]

Hi,

I've encountered a hard-to-consistently-reproduce issue with HashTable
zvals. I have code that will generate big nested \stdClass structures for
JSON encoding. It does so using classes that have methods that generate
those fields. For example, you could have a class like this:

class Block {
  public function css_classes() {
return ['x', 'y', 'z'];
  }
}

Other code would translate it into a value that would var_dump() as this:

object(stdClass)#1 (1) {
  ["css_classes"]=>
  array(3) {
[0]=>
string(1) "x"
[1]=>
string(1) "y"
[2]=>
string(1) "z"
  }
}

The template data could include multiple instances of Block. As in, a
\stdClass could be generated with multiple copies of that array content.
That data could get sent to json_encode(), which
uses ZEND_HASH_APPLY_PROTECTION/etc. to avoid recursion. I've seen
situations where that array of strings triggers that recursion check. But
it's not always, and a php-fpm restart can make it go away.

Can anyone think of why this might happen?

Thanks,
Adam

Re: [PHP-DEV] [RFC][VOTE] Closure from callable

[Dan Ackroyd]

On 16 May 2016 at 09:31, Dmitry Stogov  wrote:
> I'm sorry, I didn't follow the RFC discussion.
> In general I like the idea, but why not to use Closure constructor?
>

Hi Dmitry,

Several small to medium sized reasons that make me think it's the best way.

As Marco said, constructors cannot be passed as callbles, which for
whatever reason both myself and he seem to encounter as a problem more
than the average programmer. I had hoped to address this with this
RFC: https://wiki.php.net/rfc/callableconstructors - but the feedback
on that was massively negative so far.

Second, it's quite likely we're going to have other ways of creating
closures in the future. Having a default constructor that is 'special'
above the other named constructors is a source of API sadness for me.

> would look more readable than

I actually seem to like named constructors more than default
constructors, and am totally used to reading them. That may be down to
my dislike of how constructors have special rules in being a little
bit static, and also being instance methods at the same time.

cheers
Dan

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

Re: [PHP-DEV] [RFC] Simple Annotations

[Fleshgrinder]

On 5/16/2016 3:05 PM, Rasmus Schultz wrote:
> I'm sorry, but I think that the idea of meta-data that can't error
> somehow, somewhere, at some point, is completely unrealistic.
> 
> And I'd much rather have a simple facility that enables those errors
> to surface quickly.
> 

It should error and it should error exactly at the point when you want
to use it and at no other point. Right now they will error anytime
anyone wants to do anything with any annotation.

I fully understand the urge to directly access objects and I actually
support it and I want them to error out at the point where you try to
instantiate them. However, not when I simply access annotations in
introspection.

According to your logic I have to load the whole dependency chain, even
thought I just want to generate my documentation that might have some
annotations in use. I also need to load all my dependencies even though
I wanted to leave the security dependency out because I wanted to easily
disable the security annotation system locally for development. I even
have to load the whole dependency chain, even though I just want to
introspect the single data structure at hand without invoking anything.

Even worse if I am using a package that has Doctrine annotations but I
use it without them: /fatal error/

Nice? No!

Solutions?

Make the /simple/ annotations /simple/. ;-)

Only allow scalar data to be defined and allow userland to register
themselves for specific annotations. I mentioned this before but somehow
everyone wants something more fancy and I have no karma (even though
requested but ignored) to write my own RFC. That being said, you have
the ability to write an RFC so please just take it. :-)

Some PHP code to illustrate what I was thinking of since I am better
with code than with words. :-P

https://gist.github.com/Fleshgrinder/d26cd4751827b8c10a0dc33da32b48c3

Reflection is the wrong tool for the job to build annotation systems.
Reflection should not be used in production it should be used to
introspect data structures and reason about them or other stuff during
unit tests.

However, reflection should provide the ability to read annotations, it
just does not do anything with them by default and outputs stupid
arrays. You will definitely understand what I mean it you follow the Gist.

I am sure there is room for improvement and that I overlooked something
in my Gist. But I think it is a starting point, some additional notes:

- I do not see any benefit in annotations for parameters.
- I do not see any benefit in annotations for Generators.
- I do not see any benefit for annotations in php-src.

My proposal would include to ban annotations from php-src and make it a
pure userland functionality. This has many advantages:

- No name collisions.
- Clear policy for the future.
- php-src features are never optional.
- php-src does not provide meta-data.

Let me know what you think or if you have questions in regards to the
Gist that are unclear. (Or maybe you found mistakes.)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Sara Golemon]

On Mon, May 16, 2016 at 2:17 AM, François Laupretre  wrote:
> Le 16/05/2016 à 03:33, Larry Garfield a écrit :
>> This still sounds awfully complicated to me.  I would far, far prefer
>> the $$ syntax to special casing function aliases just to dance around
>> it.  If we had a short-function syntax then requiring a piped function
>> to have only a single argument would be both reasonable and
>> typing-efficient.  Baring that, the $$ syntax seems far nicer than
>> alternate versions of functions with implicit arguments but only in
>> certain situations.
>
> The question, here, is to determine how serious is the issue of argument
> ordering in the PHP library. It seems you don't feel it as very serious, as
> you prefer a $$ placeholder.
>
I think you're making a false equivalence here.  One can see argument
ordering consistency as a serious problem without seeing a Heath
Robinson version of call chaining as the solution to it.

I appreciate that you want to seize onto any opportunity to fix the
argument ordering consistency problem, but I don't agree that this is
the fix for it.

> The question of function aliases is not so serious because we'll need very
> few. Almost every functions have only one 'natural' argument to substitute
> as lhs. I'm not sure I understand what you mean with 'but only in certain
> situations'.
>
If it were so natural, wouldn't the original version of these
functions have been made "right" in the first place?  I fear that the
only thing we'd gain by adding all these aliases is more functions,
but without the benefit of any improvement in the argument ordering
problem because now, instead of remembering which order the argument
is in, users have to remember which alias to call.

-Sara

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

Re: [PHP-DEV] [RFC] Simple Annotations

[Rowan Collins]

On 16/05/2016 14:05, Rasmus Schultz wrote:
> I'm afraid I don't follow. Why is it a problem to simply add a
> function or class to the global namespace?
>
> << new Memoize() >>
>
> or maybe a class with factory functions for built-in annotations:
>
> << Meta::memoize() >>

Well, those particular names look quite likely to collide with users' code, 
though I guess more obviously reserved names could be used.

More generally, though, neither feels a natural fit, because of the need to 
specify a value, rather than a name. On Reflection, what would an instance of 
class Memoize look like? Could you call "new Memoize" somewhere else?

If a memoize() function was executed, what value would it return? Since you can 
only see the evaluated value, how could you detect the annotation for debugging?

Indeed, if we're interested only in values, not where they come from, are the 
following all equivalent, and the mechanics totally unndetectable by Reflection?

<>

<<(function(){return null;})()>>

function foo() { return null; }
<< foo() >>

If the function form doesn't receive any context, its only purpose would be to 
copy some runtime global state into the annotation value on first access, which 
seems like a strange thing to do. 


> I tend to agree with Richard though, that system directives really
> ought to be supported by the language with keywords rather than
> annotations.

That would be one way around it, indeed, so rather than "Future Scope", 
you could label "compiler directive" type annotations as "deliberately 
out of scope".

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [VOTE] Forbid dynamic calls to scope introspection functions

[Bishop Bettini]

>
> The RFC
>
> https://wiki.php.net/rfc/forbid_dynamic_scope_introspection
>
> is now in voting. The vote closes on 2016-05-24 with a required majority of
> 2/3.


I voted no. While I agree these appear to be exotic use cases, my quibble
boils down to the assumption these minimally exist in the wild. Several
templating systems rely on extract, and func_get_args drives several
framework collection classes. I can see userland invoking these inside of
array_map (etc) and dynamically.

I'd be a Yes if we start with a warning in 7.1 and then error in the next
major.

Re: [PHP-DEV] [RFC] Simple Annotations

[Rasmus Schultz]

Rowan,

I'm afraid I don't follow. Why is it a problem to simply add a
function or class to the global namespace?

<< new Memoize() >>

or maybe a class with factory functions for built-in annotations:

<< Meta::memoize() >>

I tend to agree with Richard though, that system directives really
ought to be supported by the language with keywords rather than
annotations.

Richard,

Regarding your point of view:

> The problem is that an annotation by definition is just meta-data. Your
> proposal however might result in fatal errors from meta-data

I agree that annotations are just meta-data. Values.

I disagree that we can't permit the use of PHP expressions to generate
those values.

You can't eliminate problems such as missing classes - and you
shouldn't. With the examples in the Attributes RFC, as well as with
e.g. Doctrine Annotations, we have the exact same problems, they're
just one step removed from the language feature, which only adds
complexity and makes it harder to debug these things.

The only work-around to an issue such as a missing class, is to
complete ignore the annotation - which leads to undefined behavior and
scenarios that are even harder to debug.

The other big problem with this position, is that it goes more or less
directly against what the community wants - the majority of those who
use annotations in PHP today, use Doctrine Annotations, and they
expect annotations as classes.

Source code can contain errors. I don't think there's really any way
around that. Even if you wittled down metadata to the absolute minimum
- a string, such as what it is in Go code, that string is invariably
going to contain something that needs to be parsed or interpreted
somehow, somewhere, at some point, and it can lead to errors.

In my opinion, it's better to allow those errors to be caught early -
for example, being able to catch syntax errors in expressions already
at load-time. The attributes RFC is much worse in this regard - you
could be lugging around all kinds of dependency errors, missing
classes and whatnot, and you'd never know about it until the day you
hit one of those annotations. Now instead, you're just stuck having to
type out redundant unit-tests to prove that every annotation is valid,
when the language could have taken care of that in a much simpler way.

The other issue is dependencies. The Attributes RFC will lead to code
with all sorts of hidden dependencies - possibly dependencies that you
can't even know about, because you can't know how your metadata is
going to be interpreted precisely. You can't know which classes your
metadata might get mapped to or how. Simple Annotations take care of
that, and they force you to e.g. `composer require` the package that
provides the annotation classes you're using - this is a good thing.

Hiding dependencies makes it really difficult for others to reason
about your code. The Attributes RFC will lead to a lot of hidden rules
- whereas Simple Annotations are simple and straight-forward, nothing
hidden or implicit, your dependencies visible and traceable, which
will lead to much better tooling. For example, an IDE or offline code
analysis tool would catch syntax errors and missing classes and warn
about those right away.

I'm sorry, but I think that the idea of meta-data that can't error
somehow, somewhere, at some point, is completely unrealistic.

And I'd much rather have a simple facility that enables those errors
to surface quickly.


On Mon, May 16, 2016 at 11:16 AM, Rowan Collins  wrote:
> On 14/05/2016 20:49, Rasmus Schultz wrote:
>>
>> Dan,
>>
>> I've added a note about special annotations to the "future scope"
>> section, naming the memoization-annotation as an example.
>
>
> This doesn't really explain how such a feature would fit it into the
> proposal. For instance, how can we avoid the syntax clashing with existing
> userland issues? Given that annotations in this proposal don't have names,
> we can't just reserve all names beginning "__" or "php\".
>
> Perhaps they would be pseudo-function calls, like <<__memoize()>>? How would
> that (or any other undefined function) act if accessed on a version that
> didn't have the feature?
>
> I realise you don't want to define the details, but an idea of what an
> annotation targeting the engine would look like would make the
> future-proofing clearer.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
>
>
> --
> 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-DEV] NEUTRAL Benchmark Results for PHP Master 2016-05-16

[lp_benchmark_robot]

Results for project PHP master, build date 2016-05-16 06:29:31+03:00
commit: bc63879
previous commit:ccf18da
revision date:  2016-05-15 14:15:04+01: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.14%  0.35%  1.23%  
  6.50%
:-|   Drupal 7.36 cgi -T1  0.15%  0.39%  0.38%  
  4.04%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.19%  1.24%  
  2.74%
:-|   bench.php cgi -T100  0.01% -0.12% 26.62%  
  0.30%
:-|  micro_bench.php cgi -T10  0.02%  0.55%  4.81%  
  2.17%
:-|  mandelbrot.php cgi -T100  0.02%  0.16% 30.17%  
  5.65%
---

* Relative Standard Deviation (Standard Deviation/Average)

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

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] [RFC] Simple Annotations

[Fleshgrinder]

On 5/13/2016 2:57 PM, Davey Shafik wrote:
> 2) I like the idea of Hacks memoize for example, how do you see those being
> implemented? Or don't you?
> 

I wrote it in the /attribute grammar/ thread and I write it here again.
Stuff like memoize should be implemented as keywords as part of the
language and not via annotations.

  memoized function f() {}

Same goes for deprecated:

  deprecated memoized function f() {}

Or other special effects:

  deprecated inlined memoized function f() {}

These things are not meta-data for userland, they are meta-data for PHP
and should be part of, well, PHP.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Simple Annotations

[Fleshgrinder]

On 5/13/2016 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
> 
> I'm announcing a simplified RFC for annotations:
> 
> https://wiki.php.net/rfc/simple-annotations
> 

-1 again, I am sorry.

The problem is that an annotation by definition is just meta-data. Your
proposal however might result in fatal errors from meta-data:

  $reflector = new ReflectionClass(User::class);
  $reflector->getAnnotations();

  // Fatal error: Uncaught Error: Class 'TableName' not found ...

This is an absolute No-Go for meta-data.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[François Laupretre]

Le 16/05/2016 à 03:33, Larry Garfield a écrit :


This still sounds awfully complicated to me.  I would far, far prefer
the $$ syntax to special casing function aliases just to dance around
it.  If we had a short-function syntax then requiring a piped function
to have only a single argument would be both reasonable and
typing-efficient.  Baring that, the $$ syntax seems far nicer than
alternate versions of functions with implicit arguments but only in
certain situations.


The question, here, is to determine how serious is the issue of argument 
ordering in the PHP library. It seems you don't feel it as very serious, 
as you prefer a $$ placeholder. If you refer to the ML history, you will 
see that a lot of people, if not most, consider it as the most serious 
PHP sadness overall. So, what I'm exploring here is the lowest price to 
pay to get rid of this issue.


The question of function aliases is not so serious because we'll need 
very few. Almost every functions have only one 'natural' argument to 
substitute as lhs. I'm not sure I understand what you mean with 'but 
only in certain situations'.


François


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

Re: [PHP-DEV] [RFC] Simple Annotations

[Rowan Collins]

On 14/05/2016 20:49, Rasmus Schultz wrote:

Dan,

I've added a note about special annotations to the "future scope"
section, naming the memoization-annotation as an example.


This doesn't really explain how such a feature would fit it into the 
proposal. For instance, how can we avoid the syntax clashing with 
existing userland issues? Given that annotations in this proposal don't 
have names, we can't just reserve all names beginning "__" or "php\".


Perhaps they would be pseudo-function calls, like <<__memoize()>>? How 
would that (or any other undefined function) act if accessed on a 
version that didn't have the feature?


I realise you don't want to define the details, but an idea of what an 
annotation targeting the engine would look like would make the 
future-proofing clearer.


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] Closure from callable

[Nikita Nefedov]

On Mon, 16 May 2016 03:56:38 +0300, Sara Golemon  wrote:

On Sun, May 15, 2016 at 11:20 AM, Nikita Nefedov   
wrote:

why would you need to support a $this->fieldName case though?


Because to not support it would be to deliberately design in a new
flavor of inconsistency into the language. $obj->memb is a property
access in PHP.  Making it suddenly mean "method" is a significant
change (and one which belongs in a major version if at all).

-Sara


The whole idea is not in the syntax here, but in the notion
that this access can only be static (so there'd be no way to
do `$cb = [$this, "methodName"]; callable($cb)` - you'd have
to call `Closure::fromCallable($cb)` instead).

If you don't like the fact that `$obj->methodName` looks like
a field access then there are ways around this.
Because we still need a static way of exporting function
references (whether it'd be as a closure or array). Other
proposals were using `$obj->method::FUNCTION` syntax or something
similar for example...

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

Re: [PHP-DEV] [RFC][VOTE] Closure from callable

[Marco Pivetta]

On 16 May 2016 at 10:31, Dmitry Stogov  wrote:

> I'm sorry, I didn't follow the RFC discussion.
> In general I like the idea, but why not to use Closure constructor?
>
> $f = new Closure("some_func");
>
> would look more readable than
>
> $f = Closure::fromCallable("some_func");
>
> Sorry, if this was already discussed before.
>
> Thanks. Dmitry.
>

Constructors can't be used as callbacks, so you wouldn't be able to map
this operation without yet another level of indirection.

A named constructor also leaves more space for later improvements, and is
quite a bit more expressive.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC][VOTE] Closure from callable

[Dmitry Stogov]

I'm sorry, I didn't follow the RFC discussion.
In general I like the idea, but why not to use Closure constructor?

$f = new Closure("some_func");

would look more readable than

$f = Closure::fromCallable("some_func");

Sorry, if this was already discussed before.

Thanks. Dmitry.


From: Dan Ackroyd 
Sent: Sunday, May 15, 2016 8:29:22 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC][VOTE] Closure from callable

Hello,

I've opened the voting for the Closure from callable RFC -
https://wiki.php.net/rfc/closurefromcallable

Just to note, some people I've spoken to have expressed a desire to
have a more powerful syntax where 'bare' function names are used,
like:

callable(someFunctionName)
callable($this->method)

I fully agree with those people, however I can't see anyway to do that
before PHP 8. It would almost certainly need some clean up of the
allowed syntax to disambiguate what `$this->method` means for:

class Foo {
public $method;
public function method() { }
}

Leaving that top-level function name available for future versions,
where we might be able to support it properly, is one of the reasons
to use the more verbose function name.

cheers
Dan

--
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