Re: [PHP-DEV] Re: [RFC][DISCUSSION] Session ID without hashing

[Stanislav Malyshev]

Hi!

> Concern has been discussed is risk of broken PRNG and predictable
> session ID. We may insist any platform must have reliable PRNG, but it
> would be good idea to have least mitigation. Reading extra bytes
> should be good enough for this purpose.

I still see no reason to change it stated in the RFC except performance
(which is irrelevant in all contexts I know of). It states the change
but omits the reason why this change is necessary. Could you please add
that part?

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

[Larry Garfield]

On 06/28/2016 04:24 PM, Rasmus Schultz wrote:

This was just an example of a value object - for example:

class HttpMethod {
 private $method;

 protected function __construct($method) {
 $this->method = $method;
 }

 public function getMethod() {
 return $this->method;
 }

 public static function get() {
 return new self("GET");
 }

 public static function post() {
 return new self("POST");
 }

 // ...
}

You could picture using a flyweight constructor inside those factory
methods maybe, and probably other patterns... I think there's plenty
of cases for "named constructors", this is just the PHP variety of
that. There are also cases (such as this one) where only certain
constructions are permitted - allowing any string for HTTP method
(e.g. wrong names, wrong case etc.) is prevented by protecting the
constructor...


A possibly uglier but useful case would be where you have a large number 
of properties in an annotation and want to pass them in by name, but not 
using an anonymous array.  (See also, my earlier Drupal examples.)


To wit:

<>
class Node {

  public static function definition() {
$def = new NodeDefinition();
$def->name = "node";
$def->label = "A Node";
$def->addLink('foo', 'bar');
// ...
return $def;
  }

  // The rest of the node class here.
}

$annotations = $class_reflection->getAnnotations();

print get_class($annotations[0]); // prints "NodeDefinition".

Or would that fail because it's not returning a self instance, but of 
another class?


Rasmus, let me know when you have a proposal together and I'll try to 
dig up time to try rendering Drupal annotations in it again. :-)


--Larry Garfield

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

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

[Rasmus Schultz]

This was just an example of a value object - for example:

class HttpMethod {
private $method;

protected function __construct($method) {
$this->method = $method;
}

public function getMethod() {
return $this->method;
}

public static function get() {
return new self("GET");
}

public static function post() {
return new self("POST");
}

// ...
}

You could picture using a flyweight constructor inside those factory
methods maybe, and probably other patterns... I think there's plenty
of cases for "named constructors", this is just the PHP variety of
that. There are also cases (such as this one) where only certain
constructions are permitted - allowing any string for HTTP method
(e.g. wrong names, wrong case etc.) is prevented by protecting the
constructor...


On Tue, Jun 28, 2016 at 9:10 PM, Pedro Cordeiro  wrote:
>
>> << HttpMethod::post() >> // equivalent to static method-call
>> HttpMethod::post()
>
>
> What would this, specifically, do? Would it call HttpMethod::post() when the
> class gets instantiated and return its return on a
> ReflectionClass::getAnnotations()? Why is it necessary to be able to
> evaluate expressions on annotations? I do agree that throwing
> errors/exceptions when classes are not found is needed (otherwise we wont be
> able to use value-objects), but evaluating expressions seems a little crazy
> for me... why should metadata be computed in runtime?

-- 
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 28 June 2016 20:10:15 GMT+01:00, Pedro Cordeiro  
wrote:
>> << HttpMethod::post() >> // equivalent to static method-call
>> HttpMethod::post()
>>
>
>What would this, specifically, do? Would it call HttpMethod::post()
>when
>the class gets instantiated and return its return on a
>ReflectionClass::getAnnotations()? Why is it necessary to be able to
>evaluate expressions on annotations?

I'm not sure if it's definitely necessary, but the stated use case was for 
factories / named constructors. PHP only has one constructor per class, so it's 
not uncommon to have static createFromX methods.

Since this will eventually evaluate as "new Foo(42)":
<< Foo(42) >>

The idea is that this would be available to call a factory instead:
<< Foo::fromRoman('XLII') >>

The neat thing being that by limiting the options to this, you can still 
extract a class name for every annotation.

I say "eventually", because as proposed, this won't actually happen until you 
explicitly ask for the "instance" of the annotation. See previous examples.

Regards,

-- 
Rowan Collins
[IMSoP]

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

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

[Pedro Cordeiro]

> << HttpMethod::post() >> // equivalent to static method-call
> HttpMethod::post()
>

What would this, specifically, do? Would it call HttpMethod::post() when
the class gets instantiated and return its return on a
ReflectionClass::getAnnotations()? Why is it necessary to be able to
evaluate expressions on annotations? I do agree that throwing
errors/exceptions when classes are not found is needed (otherwise we wont
be able to use value-objects), but evaluating expressions seems a little
crazy for me... why should metadata be computed in runtime?

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Stanislav Malyshev]

Hi!

>> Voting has opened on the RFC to change most conditions in extensions that 
>> raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead.
>>
>> RFC: https://wiki.php.net/rfc/throw_error_in_extensions 
>> 
>> PR: https://github.com/php/php-src/pull/1942 
>> 

Isn't there a case that php_error(E_ERROR) does not return? At least it
was in 5.x, I'm not sure if that didn't change. If so, we need to be
very careful here - some code may make assumptions about the things
because of previous E_ERROR conditions, and if zend_throw_error returns
where php_error didn't there might be subtle and dangerous bugs.

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

[Rasmus Schultz]

Thanks, Richard and Rowan - this gives me more to work with!

I will work on a new proposal and ask for more input when I have a
draft ready :-)


On Tue, Jun 28, 2016 at 7:56 PM, Rowan Collins  wrote:
> On 28/06/2016 17:31, Rasmus Schultz wrote:
>>
>> For another, eager construction means we can filter annotations with
>> instanceof rather than by class-name, which is much powerful, enabling
>> you to leverage inheritance - for example, you'd be able to ask
>> directly for all instances of ValidationAnnotation and get those with
>> a single call, which is incredibly useful.
>
>
> Sorry for the extra mail with only one point, but I missed this before. This
> can be achieved using the fully-qualified class-name by using is_a() or
> is_subclass_of(). This obviously needs to trigger the autoloader anyway, but
> can still avoid actually instantiating the class. (And thus, per my other
> mail, evaluating the args.)
>
> I think lazy construction (without magic stub classes) gives the best of
> both worlds here.
>
>
> --
> 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] Throw Error in Extensions

[Aaron Piotrowski]

Hi Jakub,

> On Jun 28, 2016, at 12:28 PM, Jakub Zelenka  wrote:
> 
> Hi,
>> 
>> 
> Just noticed the openssl case in X509_digest and it's obviously oversight
> by whoever added that bit because it should be warning as it's for all
> other similar fails. I'm going to change it to warning to make it
> consistent.

I noticed most others were warnings in openssl, but I did not want to make 
assumptions about what level an error should be. If an error was E_ERROR, I 
assumed there was a reason it was fatal. If you change it to a warning I'll be 
sure not to overwrite this when merging the patch.

> In general I agree with the idea but the patch should be a bit more
> sensible and considers consistency with other errors in the extension. It
> should be also reviewed by all active maintainers or regular contributors
> to the changed extensions before it gets merged so it might be a bit late
> for 7.1

I agree, either the maintainers or someone very familiar with each extension 
should examine the changes before merging. Note that this patch is only meant 
to allow catching and handling of otherwise fatal errors, not to modify overall 
error handling in each extension. I would rather individual extension 
maintainers make decisions on error levels.

Thanks!

Aaron Piotrowski



--
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 28/06/2016 17:31, Rasmus Schultz wrote:

For another, eager construction means we can filter annotations with
instanceof rather than by class-name, which is much powerful, enabling
you to leverage inheritance - for example, you'd be able to ask
directly for all instances of ValidationAnnotation and get those with
a single call, which is incredibly useful.


Sorry for the extra mail with only one point, but I missed this before. 
This can be achieved using the fully-qualified class-name by using 
is_a() or is_subclass_of(). This obviously needs to trigger the 
autoloader anyway, but can still avoid actually instantiating the class. 
(And thus, per my other mail, evaluating the args.)


I think lazy construction (without magic stub classes) gives the best of 
both worlds here.


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

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Jakub Zelenka]

Hi,

On Mon, Jun 27, 2016 at 4:17 PM, Aaron Piotrowski  wrote:

> Hello,
>
> Voting has opened on the RFC to change most conditions in extensions that
> raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead.
>
> RFC: https://wiki.php.net/rfc/throw_error_in_extensions <
> https://wiki.php.net/rfc/throw_error_in_extensions>
> PR: https://github.com/php/php-src/pull/1942 <
> https://github.com/php/php-src/pull/1942>
>
>
Just noticed the openssl case in X509_digest and it's obviously oversight
by whoever added that bit because it should be warning as it's for all
other similar fails. I'm going to change it to warning to make it
consistent.

In general I agree with the idea but the patch should be a bit more
sensible and considers consistency with other errors in the extension. It
should be also reviewed by all active maintainers or regular contributors
to the changed extensions before it gets merged so it might be a bit late
for 7.1

Cheers

Jakub

Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

[Bob Weinand]

> Am 28.06.2016 um 18:41 schrieb Nikita Popov :
> 
> On Tue, Jun 28, 2016 at 6:16 PM, Dmitry Stogov  wrote:
> 
>> Hi internals,
>> 
>> 
>> The RFC has been moved into voting stage:
>> 
>> 
>> https://wiki.php.net/rfc/async_signals
>> 
>> 
>> Thanks. Dmitry.
>> 
> 
> What about Bob's suggestion to add a flag (for disabling async signals) to
> pcntl_signal() instead of having a global option?
> 
> In any case, imho the default for this should be on, not off. Default "on"
> matches the PHP 5 behavior better than "off".
> 
> Nikita

The reason I've chosen to not pursue this:

In the next major PHP version we may remove ability of manual signal handling 
and corresponding pcntl.async_signals INI directive or pcntl_async_signals() 
function.


Thus I don't see much sense in adding complicated logic (extra parameter) if 
we're anyway going to remove that.

After all, current sync handling can be changed to add to an array and then 
read the triggered signals from that array.
Thus synchronous handling can be abolished. The only reason we really needed 
true sync dispatching before was it not being too reliable and relying on ticks.

Bob

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

[Fleshgrinder]

On 6/28/2016 6:31 PM, Rasmus Schultz wrote:
> Since the discussion isn't completely dead yet (thank you Pedro and
> Marco), I will just briefly explain what I had in mind for another
> RFC.
> 

I want to see this feature happen too but the right way, so let us just
spend some more time wrapping our heads around it. We could also discuss
and work on the RFC at a different place (GitHub with issues?), since
many people are always complaining about too many emails that are sent
to this ML.

On 6/28/2016 6:31 PM, Rasmus Schultz wrote:
> The syntax would no longer allow arbitrary expressions - instead, it
> would allow object annotations only, declared in one of three ways:
> 
> << RequiresLogin >> // equivalent to new RequiresLogin()
> 
> << Length(20) >> // equivalent to new Length(20)
> 
> << HttpMethod::post() >> // equivalent to static method-call 
> HttpMethod::post()
> 
> The latter permits you to declare and call static factory methods,
> e.g. "named constructors" for some types of annotations.
> 
> Annotations are now consistently objects, which simplifies filtering
> annotations, etc.
> 
> This declaration syntax enables better in-language analysis - because
> the declarations always include the annotation class-name, this means
> it can now support deferred as well as conditional creation, by having
> a slightly different reflection API:
> 
> $annotations = $class_reflection->getAnnotations();
> 
> At this point, we have a list of ReflectionAnnotation objects - the
> actual annotation objects have *not* been created at this point, which
> would allow for conditional evaluation, such as:
> 
> foreach ($annotations as $annotation) {
> echo $annotation->className; // => "Length" etc.
> 
> if ($annotation->classExists()) {
> var_dump($annotation->getInstance()); // => Length object, etc.
> } else {
> var_dump($annotation->getInstance()); // => UnknownAnnotation 
> object
>}
> }
> 
> The UnknownAnnotation object has three properties: class-name,
> method-name ("__construct" if constructor was used) and the list of
> arguments.
> 
> In other words, this would provide support for "optional
> dependencies", in much the same way that unserialize() does it - the
> getInstance() method will trigger autoloading, and if the class is
> unavailable, it takes this "typeless" information and puts it in a
> general object, so that the information itself isn't lost.
> 

Awesome! This is exactly the kind of thing that one wants from
reflection, information and not exceptions or worse. :)

On 6/28/2016 6:31 PM, Rasmus Schultz wrote:
> It may *seem* like this solves the optional dependency problem, but
> let me be clear, it does *not* fully address that issue, because
> something like << Method(Http::GET) >> could still fail, if the Method
> class is defined, but the Http class is not. That's a much more
> marginal case, but it's not completely unlikely that you would use
> constants from one dependency and pass them to annotation classes from
> another dependency, e.g. if the HTTP method constants were part of an
> HTTP package, and the annotation itself were part of a different
> package. Arguably it's much less likely to occur though - if you have
> the annotation package installed, most likely you have the dependent
> package of that package installed as well.
> 
> So this is much safer, but just to be clear, the only way you can make
> it any safer than that, is by completely disallowing anything but
> values as arguments to annotation constructors - which, in my opinion,
> simply isn't useful.
> 

I would argue that this should fail if the Method class from the example
exists and is actually being created. However, if the Method class does
not exist (and we construct an UnknownAnnotation stub for it) nothing
should go wrong. I mean, the assumption that the dependency of a missing
dependency is/might be missing sounds logical too me.

Of course we would need to have something like an
UnknownAnnotationArgument stub too.

Note that this allows you in consequence to create other kinds of
objects within annotations:

  << Annotation(new Argument) >> final class {}

This would allow nesting as some DocBlock libraries allow it currently.

On 6/28/2016 6:31 PM, Rasmus Schultz wrote:
> Alternatively to the above, you could imagine a simpler reflection
> facility that does eagerly construct annotations, but constructs
> UnknownAnnotation instances for missing classes - this would perhaps
> balance more towards immediate usefulness and less towards performance
> perfectionism, as it increases the chance of loading an unused
> annotation.
> 
> This would be my preference though - as previously argued, the odds of
> having a large number of unrelated annotations on the same member are
> extremely low in practice; an annotated entity tends to be a persisted
> property, a form input element, or an action method, etc... rarely do
> you mix annotations from 

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

[Rowan Collins]

Hi Rasmus,

I think you may be onto something here... :)


On 28/06/2016 17:31, Rasmus Schultz wrote:

The UnknownAnnotation object has three properties: class-name,
method-name ("__construct" if constructor was used) and the list of
arguments.


I'm not sure we need an extra UnknownAnnotation class. It seems like all 
of that information could be available on the ReflectionAnnotation 
object, so you can get it without the class being available if you want to.


If the idea is to lazily-evaluate the arguments to the annotation, that 
could be handled by storing the AST and only evaluating them when you 
call either $annotation->getInstance() or $annotation->getArguments():


use MyAnnotations\FooAnnotation as Foo;
// Class alias resolved at compile time as normal
<< Foo(time()) >>
class A {}

$class_reflection = new ReflectionClass('A');
$annotations = $class_reflection->getAnnotations();
foreach ($annotations as $annotation) {
   if ( $annotation->getClassName() == 'MyAnnotations\\FooAnnotation' ) {
   var_dump( $annotation->getArguments() ); // `time()` evaluated here
   var_dump( $annotation->getInstance() ); // `new 
MyAnnotations\FooAnnotation(time())` evaluated here

   }
}

It's not the responsibility of the ReflectionAnnotation class to worry 
about calling the autoloader, issuing errors, etc, it should just 
delegate that to the engine like any other constructor call. There's no 
need for an extra $annotation->classExists() method, either, because you 
can just say "class_exists($annotation->getClassName())".



Interestingly, this same delayed evaluation of arguments opens us up to 
include direct access to the AST as some (Nikita?) have asked for:


// Constructor argument can be any valid expression,
// however nonsensical it would be to evaluate it directly
<< Pre($a >= 42) >>
function foo($a) {}

$r = new ReflectionFunction('foo');
$annotations = $r->getAnnotations();
foreach ( $annotations as $annotation ) {
   if ( $annotation->getClassName() == 'Pre' ) {
   $ast = $annotation->getArgumentAST();
   // Now we can do funky things with the AST, like evaluating it 
in a custom context :)

   }
}


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] Asynchronous Signal Handling

[Dmitry Stogov]

pcntl.async_signals=0 leads to exactly the same behavior as it was in 5.* and 
7.0.

Allow manual handling and using TICKs.


pcntl.async_signals=1 - new behavior with interrupts.


Thanks. Dmitry.




From: Nikita Popov 
Sent: Tuesday, June 28, 2016 19:41
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

On Tue, Jun 28, 2016 at 6:16 PM, Dmitry Stogov 
> wrote:
Hi internals,


The RFC has been moved into voting stage:


https://wiki.php.net/rfc/async_signals


Thanks. Dmitry.

What about Bob's suggestion to add a flag (for disabling async signals) to 
pcntl_signal() instead of having a global option?

In any case, imho the default for this should be on, not off. Default "on" 
matches the PHP 5 behavior better than "off".

Nikita

Re: [PHP-DEV] [RFC DISCUSSION] var_info

[Fleshgrinder]

On 6/28/2016 12:44 AM, Dan Ackroyd wrote:
> The RFC doesn't seem to state any reason why this should be in core,
> rather than in a userland library.
>

I will extend the RFC on the weekend with the missing information,
thanks for the heads up.

On 6/28/2016 4:21 AM, Jesse Schalken wrote:
> I think IEEE 754 only specifies that -0.0 and +0.0 be considered equal for
> the purpose of numeric equality. That doesn't necessarily mean converting
> to a string in some manner should produce the same result. It is already
> the case that (string)(float)-0.0 === "-0" and this is how I check for -0.0
> in PHP.
> 

Exactly, the question is whether this function should report it or not.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC DISCUSSION] Error Storage Behavior

[Fleshgrinder]

On 6/27/2016 9:53 PM, Stanislav Malyshev wrote:
> Hi!
> 
>> Currently error_get_last() always contains the last error that occurred,
>> however, this is actually not desired if the last error was an exception
>> that was caught.
>>
>> https://github.com/php/php-src/pull/1936
> 
> I think conditioning warnings on whether exception is caught or not is a
> very bad idea. However, having _either_ exception _or_ PHP error and not
> producing both (except in the case where uncaught exception becomes
> fatal error I guess) may be a good idea, but it needs careful checking
> of the implications. In general, old error mechanism and exceptions are
> not very good combination, and using them together may be troublesome.
> 
> It's definitely not "just a bug fix" - it needs careful check of what
> exactly happens when.
> 

This is exactly how I see this situation too and why I mailed the list
while asking for feedback.

I think the actual problem from the bug report is not related to the
provided patch that I updated a bit, the problem is as far as I can tell
within the DateTime::__construct method were the error mode is changed
to E_THROW but upon throwing a warning is generated as well. I had a
look at other implementations that change the mode but they did not
behave the same.

I am not familiar enough with all the code yet to simply point out what
is actually wrong but will definitely invest more time unless somebody
else who knows more does and simply fixes it.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

[Nikita Popov]

On Tue, Jun 28, 2016 at 6:16 PM, Dmitry Stogov  wrote:

> Hi internals,
>
>
> The RFC has been moved into voting stage:
>
>
> https://wiki.php.net/rfc/async_signals
>
>
> Thanks. Dmitry.
>

What about Bob's suggestion to add a flag (for disabling async signals) to
pcntl_signal() instead of having a global option?

In any case, imho the default for this should be on, not off. Default "on"
matches the PHP 5 behavior better than "off".

Nikita

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

[Rasmus Schultz]

Note that I only make comparisons with doc-blocks to point out the
fact that, functionally, they would not be very different from an
annotation feature that solely permits you to annotate with values. A
doc-block is a string, which is a value - an
array/int/float/string/bool is a value. It's only very slightly better
than a bare string, in the sense that neither doc-blocks nor simple
values permit any kind of definition of which annotations are actually
available, hence offer no means of validation of that data (except at
run-time by a userland facility), provides no support for static
analysis, no IDE support, no clear indication of real dependencies,
and so on.

Since the discussion isn't completely dead yet (thank you Pedro and
Marco), I will just briefly explain what I had in mind for another
RFC.

This would be largely based on my previous proposal:

https://wiki.php.net/rfc/simple-annotations

But with the following differences.

The syntax would no longer allow arbitrary expressions - instead, it
would allow object annotations only, declared in one of three ways:

<< RequiresLogin >> // equivalent to new RequiresLogin()

<< Length(20) >> // equivalent to new Length(20)

<< HttpMethod::post() >> // equivalent to static method-call HttpMethod::post()

The latter permits you to declare and call static factory methods,
e.g. "named constructors" for some types of annotations.

Annotations are now consistently objects, which simplifies filtering
annotations, etc.

This declaration syntax enables better in-language analysis - because
the declarations always include the annotation class-name, this means
it can now support deferred as well as conditional creation, by having
a slightly different reflection API:

$annotations = $class_reflection->getAnnotations();

At this point, we have a list of ReflectionAnnotation objects - the
actual annotation objects have *not* been created at this point, which
would allow for conditional evaluation, such as:

foreach ($annotations as $annotation) {
echo $annotation->className; // => "Length" etc.

if ($annotation->classExists()) {
var_dump($annotation->getInstance()); // => Length object, etc.
} else {
var_dump($annotation->getInstance()); // => UnknownAnnotation object
   }
}

The UnknownAnnotation object has three properties: class-name,
method-name ("__construct" if constructor was used) and the list of
arguments.

In other words, this would provide support for "optional
dependencies", in much the same way that unserialize() does it - the
getInstance() method will trigger autoloading, and if the class is
unavailable, it takes this "typeless" information and puts it in a
general object, so that the information itself isn't lost.

It may *seem* like this solves the optional dependency problem, but
let me be clear, it does *not* fully address that issue, because
something like << Method(Http::GET) >> could still fail, if the Method
class is defined, but the Http class is not. That's a much more
marginal case, but it's not completely unlikely that you would use
constants from one dependency and pass them to annotation classes from
another dependency, e.g. if the HTTP method constants were part of an
HTTP package, and the annotation itself were part of a different
package. Arguably it's much less likely to occur though - if you have
the annotation package installed, most likely you have the dependent
package of that package installed as well.

So this is much safer, but just to be clear, the only way you can make
it any safer than that, is by completely disallowing anything but
values as arguments to annotation constructors - which, in my opinion,
simply isn't useful.

Alternatively to the above, you could imagine a simpler reflection
facility that does eagerly construct annotations, but constructs
UnknownAnnotation instances for missing classes - this would perhaps
balance more towards immediate usefulness and less towards performance
perfectionism, as it increases the chance of loading an unused
annotation.

This would be my preference though - as previously argued, the odds of
having a large number of unrelated annotations on the same member are
extremely low in practice; an annotated entity tends to be a persisted
property, a form input element, or an action method, etc... rarely do
you mix annotations from different domains onto the same member;
annotations that are applicable to a given domain are usually relevant
to a consumer belonging to the same (or a closely related) domain, so
this performance concern is mostly a theoretical micro optimization.

For another, eager construction means we can filter annotations with
instanceof rather than by class-name, which is much powerful, enabling
you to leverage inheritance - for example, you'd be able to ask
directly for all instances of ValidationAnnotation and get those with
a single call, which is incredibly useful.

Anyways, let me know your feelings 

[PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

[Dmitry Stogov]

Hi internals,


The RFC has been moved into voting stage:


https://wiki.php.net/rfc/async_signals


Thanks. Dmitry.

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

[Pedro Cordeiro]

I completely agree with Marco. Throwing class-loading errors for
value-object classes is alright. For logic-parsing inside annotations, I
don't feel any need for it. Metadata should be static, IMO, but it could
very well be (and should be) value-objects.

>At the end of the day, what we end up with will have all of the same
>issues we have with php-doc blocks and existing libraries.
>
>I don't understand how such a feature would be useful to anybody?

As an addition, I don't think this feature should ADD new functionality to
those already present on DocBlocks. I just feel like docblocks are an ugly
hack for the lack of native annotations. Pasting from a previous discussion
in this same list, Rowan and I were discussing whether to add a native
docblock-annotation-retrieval feature or a native annotation syntax:

1) It might not be objectively bad to add this feature in docblocks, but it
will be objectively wrong to keep calling them "DocBlocks" if they are no
longer documentation-only blocks.

2) Even though PHP already treats docblocks differently from comments,
that's not the common view on userland, nor is explained on the manuals.
There are no separate entries to explain docblocks, and no mention to them
on the "Comments" page. The Reflection method to retrieve DocBlocks is
"getDocCOMMENT", which suggests they are comment that do not affect runtime
behaviour.

We'd have to update the comments page to say "'/*' starts a comment, unless
if they're immediately followed by another asterisk ('/**'), in which case
it may or may not be a comment, depends on the following token". It's very
confusing.

3) To make this work within docblocks, we'd have to get rid of at least one
configuration setting (opcode.save_comments).

4) Dockblocks are stripped from obfuscators and transpilers, which are a
part of the ecosystem and do affect users, even if they are not first-class
citizens here.

Annotations in dockblocks are hard to understand because they they may or
may not be runtime-affecting annotations and there is no way to tell.

I hate this comparison with docblock annotations, because they are an UGLY
HACK. It works wonderfully, yes, but so do global variables, singletons and
what-not, and we are not using them anymore, are we? Adding this very same
feature that already exists in userland as a dedicated syntax would fix a
lot of issues, cited above. There is no need to evaluate logic inside
annotations, let them be value-objects, let it throw errors autoloading
said objects, and let's get this rolling.

Please, don't embargo this ONCE again. It's a very much needed feature, and
people want it! There have been innumerous discussions on reddit, and
almost everyone agrees annotations are a missing feature and
comment-annotations are an ugly hack for the lack of native syntax.

Please, make this happen.

2016-06-28 11:12 GMT-03:00 Marco Pivetta :

> Hi Rasmus,
>
> On 27 June 2016 at 20:37, Rasmus Schultz  wrote:
>
> > Tonight I started trying to write a proposal for even more simplified
> > annotations, e.g. something simple enough that it cannot result in
> > fatal errors. I eventually gave up, and here's why.
> >
> > Essentially, if you have to restrict yourself to things that cannot
> > under any circumstances error out, the only things you can use are
> > constant scalar values - even constant scalar expressions could not be
> > allowed, because even those could error when CONST_NAME or
> > Class::CONST_NAME aren't defined.
> >
> > So, in a nutshell, what you're saying (Richard) is that annotations
> > can only consist of scalar values, and possibly arrays of values? (and
> > I don't even see your gist doing that - it's just invoking closures,
> > as far as I can tell, and any of those could error, or not?)
> >
> > So, regardless of syntax, literally the only annotation data allowed
> > would be blatantly simple things like:
> >
> > ["max_length" => 20]
> >
> > ["data_type" => "int"]
> >
> > Or in other words, constant arrays, int, string, float and bool
> > values. Nothing else.
> >
> > Nothing can depend on any kind of external symbol (class names,
> > constants, etc.) since any such reference can cause an error.
> >
> > No static analysis or type-checking of any kind can ever be performed
> > - no assertions or declarations can be made about the shape or types
> > of metadata, at all.
> >
> > The problem is, that's simply not useful.
> >
>
> That's actually what doctrine/annotations has been for a while  tho, and a
> lot of people rely just on that.
> The data-structure is still enforced by a VO-style class (the annotation
> itself) in the library, though.
>
> It would still be very useful, in my opinion.
>
> Note that the existing annotation libs out there do indeed trigger
> autoloading for referenced class constants.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

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

[Marco Pivetta]

Hi Rasmus,

On 27 June 2016 at 20:37, Rasmus Schultz  wrote:

> Tonight I started trying to write a proposal for even more simplified
> annotations, e.g. something simple enough that it cannot result in
> fatal errors. I eventually gave up, and here's why.
>
> Essentially, if you have to restrict yourself to things that cannot
> under any circumstances error out, the only things you can use are
> constant scalar values - even constant scalar expressions could not be
> allowed, because even those could error when CONST_NAME or
> Class::CONST_NAME aren't defined.
>
> So, in a nutshell, what you're saying (Richard) is that annotations
> can only consist of scalar values, and possibly arrays of values? (and
> I don't even see your gist doing that - it's just invoking closures,
> as far as I can tell, and any of those could error, or not?)
>
> So, regardless of syntax, literally the only annotation data allowed
> would be blatantly simple things like:
>
> ["max_length" => 20]
>
> ["data_type" => "int"]
>
> Or in other words, constant arrays, int, string, float and bool
> values. Nothing else.
>
> Nothing can depend on any kind of external symbol (class names,
> constants, etc.) since any such reference can cause an error.
>
> No static analysis or type-checking of any kind can ever be performed
> - no assertions or declarations can be made about the shape or types
> of metadata, at all.
>
> The problem is, that's simply not useful.
>

That's actually what doctrine/annotations has been for a while  tho, and a
lot of people rely just on that.
The data-structure is still enforced by a VO-style class (the annotation
itself) in the library, though.

It would still be very useful, in my opinion.

Note that the existing annotation libs out there do indeed trigger
autoloading for referenced class constants.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] PHP 7.1.0 Alpha 2 Released

[Martin Keckeis]

2016-06-28 12:37 GMT+02:00 Joe Watkins :

> Hi,
>
> The second alpha for 7.1.0 was just released and can be downloaded from:
>
> https://downloads.php.net/~krakjoe/
>
> The Windows binaries are available at
>
> http://windows.php.net/qa/
>
> Please test it carefully, and report any bugs in the bug system.
> The next release will be tagged on Tuesday June 21st and released on
> Thursday June 23rd.
>
> php-7.1.0alpha2.tar.bz2
> SHA256 hash:
> e545c6bc229cf27d0540c8277da5b369c5de0e9c5c723d6b26902b3791d8795d
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJXclLvAAoJEJZAoYTDlTxVWFgQAIudU5sctzS/U8n/eDXpQlle
> MeRD6S6b0YyRt1AFcsu9+xyaacukgrSEYPBQfkV09842LsnjY3mCpyMAurSg6VQN
> iQ2tvnahAWkURBqBzUPAN3imkRxUxWD6VtKBcCgX5QLSbGWqz89mgknB2LEx9jm0
> jqV69jERv7gKLoUZl6tv3G61GbCz6c4YE9JykWPhXjGilYAm0AhvqMB954C8P9Ye
> z2CTKxEPFepg5DJ59ElGKQfxp0UWidNr61I0UfHfCYWEAAYs7d6kMZP40aA7vXfQ
> vDc2ZCvCDwX6jiwVcBlMPPd0oDBmxZNXDQi1mhR7T/1O6TaRW2u75CaxXbmUwvwc
> usKsYFKlPhdoLUNRPa/2OQ5aV8x8t8rVHpMHkYEaFNa9GK4GUyvmF4vGYLcsmsSP
> DmMDk1ji7qVo5OQ8VBacK1YpJVrkMulf+lsgregUHT7U1IlB+z9g84y0Vz79Jzp4
> 7CncUELNNmVq8qi33PeNWL7zbxCZ4eU/X3bCMgqpM17P+h1JW1PxMQAZQABnEjEf
> 0M3QU4/OKElgPYcNNisNTQOpvcb+Aytr0mwq9qxTO44cCFq5mRvWa6oi+OggtzRM
> rKKWPOLqr6UD/3dzx/dY+3ZzNkco//PqsQTMTnVX080xh+CLvN75uCHp/KKq/wz4
> SOGChuIcDtWLntr3C3UM
> =qNoD
> -END PGP SIGNATURE-
>
>
> php-7.1.0alpha2.tar.gz
> SHA256 hash:
> fc0ff6857851f4808aa7df84589ab6bb3ba1a2c9158f5838f7460bdd79c66f44
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJXclLzAAoJEJZAoYTDlTxVq4MQAKqDYLh0kQcE65Qpb0xgSUgy
> 4JOX7CQVXxSwObEH1JWVqvGMRhQ0Cklir6Lm4sflCx1BgijD/O3j+lSn95/UQ1d3
> udDhwS9oQeprtrxTNMM8ia3GBIxEUHjd2/MRPavXppEDXsKzuMG+WyzvQjie9lgl
> kyMpoyPOyOxiF36FKqfMkJtpesUdhQp45eGOUPzuP/e9Gs6qz8bfV/EeL6pUlejw
> J50y7BI766ozxklcu8nHKwy5nZ7BNKnYOcUInv2/pbtkLA7rfASOI8D+NUA9AM7Q
> o8iTCa4s1nWWpwijykRURyQP9prtKBihpihMmNCZG5NHOrYeeU88moLUDEznNpq6
> dNhozKEUho8hK6Z7fS3wDcC3sHhiDBL6ETHsUTe0LGbJhXahN15xVdTLwkFIbfQX
> sBhXZ7vXHspNxUuC9+dgvbHJmza8utuzSd6jlL92KYlldcxa341iFOQG57snhECf
> LuY3wcalZd7YhaaLMyFu6yZBA7uBM09QpRtIdMaFiJVALA3695RqAT3NyIn3APCR
> SxWUjJ9J5XJbhTl7zJTKqg7xVL+eSZIseJ9WG4StIILH8p5CF6ByIp5Af8CLdBkM
> YKbWV65oALjLopb3GP9SxN4HsedWeJBnitvlasZ5LM4prFm+9pVDG7VDDaGCAKnN
> JHOk4qMCTBKrAqXkI02j
> =wF16
> -END PGP SIGNATURE-
>
>
> php-7.1.0alpha2.tar.xz
> SHA256 hash:
> e6e76836b8d9b94bddcd56a33d62d22b76c742e2148abf89e164c74fc63eaf5f
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJXclL2AAoJEJZAoYTDlTxVOcQQAJmxpUw6t2WWrF2HTYvieono
> L/9+0zCUT8n4yLSxtE5zMOtcw8KqwLGwgOtXLj70pSCK6G9L/j/V30Jpha6yuCg5
> LBuQDRW9MqW6JD8GrIBpSSYdGrCofwj/AwQaNPbUqkb3y113Gzu6w1MXT0qjMIzo
> hDAVgxkSMYtz/HO/8V/TL2Sowxc7+oy5eTtmVzK/oOZ7M1QtbyJMZGUFuDGUl3zZ
> 3IQ0S4vUtkJMYftL8yLRxl4i5Ru5GLIFwf20TG7rQdVfbC/8xPBwsxSP83qZ8LHN
> KZs4dhhamyookJUfJ+vLH5x4N0u2ohdj/lVP2onQYwHGz7o4Pn1OCrZDqym5k+Y+
> o/cIHUx3G8yHID18YBjcZ3YB6lKobezSCJ1kRom6bVZQn0GUM7xXHBwOyqQYy3lj
> LxbBr0nZMyjx8apQAv6JjRZ/54qcvWXCVogZ9ilnEVkkTdlL3vXNcf3Cj1AmNBIz
> yUSwXeJ/ctrZvX31kROPG8j6dL65qC0YuJPLNxxWhSgOprMrb7e8UG0AeZ7acfgh
> qXsfqC7PHIJOPjSQuMX3egWNX8ZsysKyWuM8irj+RUB8IdCGVekq8ORvHNt9BNI6
> lpEVWqYhZfS+/PMMxhFORqA7a4X4YD8L4Pe12oQm28FSVA7Ur2BZt8rBPTgXn0x0
> 05WIrRHIxIBaikkQKpo2
> =TYvS
> -END PGP SIGNATURE-
>
> Cheers
> Joe
>

Hello,

this is just awesome Anatol!
I've waited for UTF-8 support for a really long time...and now nearly
missed it in the release notes :-)

https://github.com/php/php-src/commit/3d3f11ede4cc7c83d64cc5edaae7c29ce9c6986f

Best regards

[PHP-DEV] Re: [RFC][DISCUSSION] Session ID without hashing

[Yasuo Ohgaki]

Hi all,

On Wed, Apr 6, 2016 at 2:47 PM, Yasuo Ohgaki  wrote:
> Session module does not require hashing to generate session ID. This
> RFC removes hashing from session module and enable use_strict_mode as
> an insurance for broken RNG.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> Comments are appreciated!

It's been a while since last discussion.
I would like to add this change to session module at least for PHP 7.1.

Concern has been discussed is risk of broken PRNG and predictable
session ID. We may insist any platform must have reliable PRNG, but it
would be good idea to have least mitigation. Reading extra bytes
should be good enough for this purpose.

I also changed minimum length of session ID from 32 to 22 for better
compatibility. 22 is the length with MD5 hash and
hash_bits_per_character=6.

PR would be updated soon. I would like to start vote after PR update,
so please post comments if any.

Thank you.

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

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

[PHP-DEV] PHP 7.1.0 Alpha 2 Released

[Joe Watkins]

Hi,

The second alpha for 7.1.0 was just released and can be downloaded from:

https://downloads.php.net/~krakjoe/

The Windows binaries are available at

http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.
The next release will be tagged on Tuesday June 21st and released on
Thursday June 23rd.

php-7.1.0alpha2.tar.bz2
SHA256 hash:
e545c6bc229cf27d0540c8277da5b369c5de0e9c5c723d6b26902b3791d8795d
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJXclLvAAoJEJZAoYTDlTxVWFgQAIudU5sctzS/U8n/eDXpQlle
MeRD6S6b0YyRt1AFcsu9+xyaacukgrSEYPBQfkV09842LsnjY3mCpyMAurSg6VQN
iQ2tvnahAWkURBqBzUPAN3imkRxUxWD6VtKBcCgX5QLSbGWqz89mgknB2LEx9jm0
jqV69jERv7gKLoUZl6tv3G61GbCz6c4YE9JykWPhXjGilYAm0AhvqMB954C8P9Ye
z2CTKxEPFepg5DJ59ElGKQfxp0UWidNr61I0UfHfCYWEAAYs7d6kMZP40aA7vXfQ
vDc2ZCvCDwX6jiwVcBlMPPd0oDBmxZNXDQi1mhR7T/1O6TaRW2u75CaxXbmUwvwc
usKsYFKlPhdoLUNRPa/2OQ5aV8x8t8rVHpMHkYEaFNa9GK4GUyvmF4vGYLcsmsSP
DmMDk1ji7qVo5OQ8VBacK1YpJVrkMulf+lsgregUHT7U1IlB+z9g84y0Vz79Jzp4
7CncUELNNmVq8qi33PeNWL7zbxCZ4eU/X3bCMgqpM17P+h1JW1PxMQAZQABnEjEf
0M3QU4/OKElgPYcNNisNTQOpvcb+Aytr0mwq9qxTO44cCFq5mRvWa6oi+OggtzRM
rKKWPOLqr6UD/3dzx/dY+3ZzNkco//PqsQTMTnVX080xh+CLvN75uCHp/KKq/wz4
SOGChuIcDtWLntr3C3UM
=qNoD
-END PGP SIGNATURE-


php-7.1.0alpha2.tar.gz
SHA256 hash:
fc0ff6857851f4808aa7df84589ab6bb3ba1a2c9158f5838f7460bdd79c66f44
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJXclLzAAoJEJZAoYTDlTxVq4MQAKqDYLh0kQcE65Qpb0xgSUgy
4JOX7CQVXxSwObEH1JWVqvGMRhQ0Cklir6Lm4sflCx1BgijD/O3j+lSn95/UQ1d3
udDhwS9oQeprtrxTNMM8ia3GBIxEUHjd2/MRPavXppEDXsKzuMG+WyzvQjie9lgl
kyMpoyPOyOxiF36FKqfMkJtpesUdhQp45eGOUPzuP/e9Gs6qz8bfV/EeL6pUlejw
J50y7BI766ozxklcu8nHKwy5nZ7BNKnYOcUInv2/pbtkLA7rfASOI8D+NUA9AM7Q
o8iTCa4s1nWWpwijykRURyQP9prtKBihpihMmNCZG5NHOrYeeU88moLUDEznNpq6
dNhozKEUho8hK6Z7fS3wDcC3sHhiDBL6ETHsUTe0LGbJhXahN15xVdTLwkFIbfQX
sBhXZ7vXHspNxUuC9+dgvbHJmza8utuzSd6jlL92KYlldcxa341iFOQG57snhECf
LuY3wcalZd7YhaaLMyFu6yZBA7uBM09QpRtIdMaFiJVALA3695RqAT3NyIn3APCR
SxWUjJ9J5XJbhTl7zJTKqg7xVL+eSZIseJ9WG4StIILH8p5CF6ByIp5Af8CLdBkM
YKbWV65oALjLopb3GP9SxN4HsedWeJBnitvlasZ5LM4prFm+9pVDG7VDDaGCAKnN
JHOk4qMCTBKrAqXkI02j
=wF16
-END PGP SIGNATURE-


php-7.1.0alpha2.tar.xz
SHA256 hash:
e6e76836b8d9b94bddcd56a33d62d22b76c742e2148abf89e164c74fc63eaf5f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCAAGBQJXclL2AAoJEJZAoYTDlTxVOcQQAJmxpUw6t2WWrF2HTYvieono
L/9+0zCUT8n4yLSxtE5zMOtcw8KqwLGwgOtXLj70pSCK6G9L/j/V30Jpha6yuCg5
LBuQDRW9MqW6JD8GrIBpSSYdGrCofwj/AwQaNPbUqkb3y113Gzu6w1MXT0qjMIzo
hDAVgxkSMYtz/HO/8V/TL2Sowxc7+oy5eTtmVzK/oOZ7M1QtbyJMZGUFuDGUl3zZ
3IQ0S4vUtkJMYftL8yLRxl4i5Ru5GLIFwf20TG7rQdVfbC/8xPBwsxSP83qZ8LHN
KZs4dhhamyookJUfJ+vLH5x4N0u2ohdj/lVP2onQYwHGz7o4Pn1OCrZDqym5k+Y+
o/cIHUx3G8yHID18YBjcZ3YB6lKobezSCJ1kRom6bVZQn0GUM7xXHBwOyqQYy3lj
LxbBr0nZMyjx8apQAv6JjRZ/54qcvWXCVogZ9ilnEVkkTdlL3vXNcf3Cj1AmNBIz
yUSwXeJ/ctrZvX31kROPG8j6dL65qC0YuJPLNxxWhSgOprMrb7e8UG0AeZ7acfgh
qXsfqC7PHIJOPjSQuMX3egWNX8ZsysKyWuM8irj+RUB8IdCGVekq8ORvHNt9BNI6
lpEVWqYhZfS+/PMMxhFORqA7a4X4YD8L4Pe12oQm28FSVA7Ur2BZt8rBPTgXn0x0
05WIrRHIxIBaikkQKpo2
=TYvS
-END PGP SIGNATURE-

Cheers
Joe

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-06-28

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-28 06:30:25+03:00
commit: ae8cf3cb
previous commit:e539823
revision date:  2016-06-27 14:23:00-07: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.07% -0.13%  0.31%  
  7.43%
:-|   Drupal 7.36 cgi -T1  0.26%  0.01% -0.68%  
  5.03%
:-|   MediaWiki 1.23.9 cgi -T5000  0.16%  0.09%  1.15%  
  4.16%
:-|   bench.php cgi -T100  0.02%  0.01% 27.57%  
 -7.48%
:-|  micro_bench.php cgi -T10  0.01%  0.05%  4.05%  
  0.07%
:-|  mandelbrot.php cgi -T100  0.01%  0.49% 30.36%  
 -3.34%
---

* 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-06-28/

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] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Dmitry Stogov]

Everything fine now.


From: Pierre Joye 
Sent: Tuesday, June 28, 2016 5:39:08 AM
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and 
any additional overhead).

hi,

On Fri, Jun 24, 2016 at 5:20 PM, Dmitry Stogov  wrote:
> Hi internals,
>
>
> Please review the RFC https://wiki.php.net/rfc/async_signals

Travis is not happy in ZTS, can you check please?

https://travis-ci.org/php/php-src/jobs/139981256

--
Pierre

@pierrejoye | http://www.libgd.org