Re: [PHP-DEV] Soft-reserve "void" class name

[Sara Golemon]

On Tue, May 19, 2015 at 9:16 AM, Levi Morrison  wrote:
> I strongly disagree with this action. These types required an RFC; why
> should this be different? Also note that neither of the reserve
> typename RFC were unanimous.
>
> Furthermore, we are past the RFC stage. We are *supposed to already
> have an alpha* by now and we are proposing new changes?. Please stick
> to our established rules and release timetables as much as possible,
> thank you.
>
While I agree that we should be wary of anything which break process,
I think we should give some thought (possibly an RFC thought) to
whether or not Documentation-only changes, such as what Nikita
suggested, are actual violations of a feature freeze.

Could one put up an RFC for "void" reservation right up to the release
date of 7.0.0-final? I would say "yes".   Such an RFC is
documentation-only and has no code behind it.  Therefore it would have
no impact on alpha/beta/rc testing.  It's really a langspec RFC more
than a runtime RFC to be quite honest.

-Sara

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

[PHP-DEV] Throwable Interface RFC

[Aaron Piotrowski]

Hi all!

I’ve registered on the wiki with username trowski and would like to request 
write access so I can create an RFC for the PR at 
https://github.com/php/php-src/pull/1284

Thanks!

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

[PHP-DEV] Re: Soft-reserve "void" class name

[Benoit Schildknecht]

Le Tue, 19 May 2015 17:28:34 +0200, Nikita Popov  a  
écrit:



Hi internals!

For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether  
this
should be called "void" or "null" - this discussion should be held when  
an

RFC comes up, however we need to keep both options open until then.
(Currently only "null" is reserved.)

If people think that this requires a vote, I'll open one.

Thanks,
Nikita

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



Hi,

While I'm impatient to see "void" in the engine, we should follow the  
process rules. This is something that have to go through an RFC. If we  
implement it, even a soft reservation, without following the process, it  
opens the door to all kind of dangerous situations.


So while I like your idea, it shouldn't be implemented before 7.1

Regards.

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

Re: [PHP-DEV] Soft-reserve "void" class name

[Rowan Collins]

On 19 May 2015 17:21:58 BST, Levi Morrison  wrote:
>On a related note it is unclear what BC breaks are exactly allowed in
>minor releases. Adding new reserved types is a BC break, but it was
>done in PHP 5.4 with `callable`. We should solidify what we do and do
>not allow in minor releases for the PHP 7 release series.

5.4 is the wrong example to look at for BC precedent. It was immediately 
*after* 5.4's large number of changes (which were largely refugees from the 
sinking of 6.0) that a policy was adopted, and followed for 5.5, 5.6, and 7.0.

It still leaves some room for controversial interpretation, but it certainly 
disallows many of the things that happened in 5.4 outside of a major release, 
and this is by design.

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

Regards,
-- 
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Soft-reserve "void" class name

[Peter Cowburn]

On 19 May 2015 at 17:16, Levi Morrison  wrote:

> I strongly disagree with this action. These types required an RFC; why
> should this be different? Also note that neither of the reserve
> typename RFC were unanimous.
>
> Furthermore, we are past the RFC stage. We are *supposed to already
> have an alpha* by now and we are proposing new changes?. Please stick
> to our established rules and release timetables as much as possible,
> thank you.
>

To be fair, this change does not change a single byte of code. It's just
adding another type to the "reserved" list (to be documented) in the
manual. Unless I'm mistaken.

If the above really is the case, then why not stick up an RFC and vote.?

P.S. I'm not 100% clear on the outcome of all of these votes on what is
"reserved" and whether any of those give warnings/etc. in PHP 7; maybe
someone could give me an executive summary off-list? :)


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

Re: [PHP-DEV] Soft-reserve "void" class name

[Levi Morrison]

On Tue, May 19, 2015 at 10:16 AM, Levi Morrison  wrote:
> I strongly disagree with this action. These types required an RFC; why
> should this be different? Also note that neither of the reserve
> typename RFC were unanimous.
>
> Furthermore, we are past the RFC stage. We are *supposed to already
> have an alpha* by now and we are proposing new changes?. Please stick
> to our established rules and release timetables as much as possible,
> thank you.

On a related note it is unclear what BC breaks are exactly allowed in
minor releases. Adding new reserved types is a BC break, but it was
done in PHP 5.4 with `callable`. We should solidify what we do and do
not allow in minor releases for the PHP 7 release series.

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

Re: [PHP-DEV] Soft-reserve "void" class name

[Levi Morrison]

I strongly disagree with this action. These types required an RFC; why
should this be different? Also note that neither of the reserve
typename RFC were unanimous.

Furthermore, we are past the RFC stage. We are *supposed to already
have an alpha* by now and we are proposing new changes?. Please stick
to our established rules and release timetables as much as possible,
thank you.

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

Re: [PHP-DEV] Soft-reserve "void" class name

[Julien Pauli]

On Tue, May 19, 2015 at 5:28 PM, Nikita Popov  wrote:

> Hi internals!
>
> For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
> that we have the ability to introduce them as typehints in a 7.x release.
> "Soft" here means that we only document these names as being reserved and
> don't throw an error when they're used.
>
> I'd like to add "void" to this list, so we have the option to introduce a
> void return type in PHP 7.x. I've seen some disagreement as to whether this
> should be called "void" or "null" - this discussion should be held when an
> RFC comes up, however we need to keep both options open until then.
> (Currently only "null" is reserved.)
>
> If people think that this requires a vote, I'll open one.
>

I'm OK with it.


Julien

Re: [PHP-DEV] Soft-reserve "void" class name

[Mariano Iglesias]

+1

[PHP-DEV] Soft-reserve "void" class name

[Nikita Popov]

Hi internals!

For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.

I'd like to add "void" to this list, so we have the option to introduce a
void return type in PHP 7.x. I've seen some disagreement as to whether this
should be called "void" or "null" - this discussion should be held when an
RFC comes up, however we need to keep both options open until then.
(Currently only "null" is reserved.)

If people think that this requires a vote, I'll open one.

Thanks,
Nikita

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

Re: [PHP-DEV] trigger GC before memory limit is exhausted

[Dan Ackroyd]

On 19 May 2015 at 14:28, Rowan Collins  wrote:
> Dan Ackroyd wrote on 19/05/2015 14:08:
>>
>> * When gc_collect_cycles is called (and potentially other functions),
>> at the end of that function check whether the amount of memory being
>> used is less than reset level for each trigger. If so reduce the
>> current memory limit to the lowest trigger level.
>
>
> The only flaw I see in this approach is that the majority of memory
> deallocation is done transparently be the ref-counting mechanism, not any
> particular function, and the user should be able to trigger this manually.

Good point, I'll think about that.


Danack wrote:
> I'll wait for some feedback, then write an RFC
Actually no I won't, I'll try to implement it as an extension first.


cheers
Dan

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

Re: [PHP-DEV] trigger GC before memory limit is exhausted

[Rowan Collins]

Dan Ackroyd wrote on 19/05/2015 14:08:

* When gc_collect_cycles is called (and potentially other functions),
at the end of that function check whether the amount of memory being
used is less than reset level for each trigger. If so reduce the
current memory limit to the lowest trigger level.


The only flaw I see in this approach is that the majority of memory 
deallocation is done transparently be the ref-counting mechanism, not 
any particular function, and the user should be able to trigger this 
manually.


For instance, you might have an EntityRepository which caches all the 
entities it's loaded thus far in the script to save DB round trips, and 
calling clearCache() on this repository might free a significant amount 
of memory.


It would probably make sense for the memory level to be checked against 
reset levels immediately after the low-memory callback returns, so that 
users can deliberately take advantage of such deallocations. However, 
that still leaves the case of that method being called during normal 
flow, and requiring a call to gc_collect_cycles just for the side-effect 
of resetting memory limits seems a bit odd.


I don't know enough about the memory manager to know, but presumably at 
the moment memory_limit is checked on every allocation? Could a similar 
check be made on deallocation?


Having multiple levels configured doesn't actually have any extra 
performance cost, except in the case where they are all passed at once - 
you just store the "current" level, and test whether you have reached 
the next level up or down. If a single deallocation drops you from 20MB 
to 2MB, you first register that the 16MB reset limit has been reached, 
and *only then* perform an extra check if the 8MB reset limit has also 
been reached.


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] trigger GC before memory limit is exhausted

[Dan Ackroyd]

On 19/05/2015 00:07, Christoph Becker wrote:
> What happens if the soft limit is exhausted, but the GC can free only a
> little memory?  That might trigger the GC shortly afterwards again and
> again.

The usual way to stop this sort of flapping is to set the point at
which the alarm gets reset to be significantly lower than the point at
which an alarm is triggered in the first place. And as Rowan said, the
current situation is that applications just crash when they run out of
memory, so a little slow but not 50x response would still be better.

On 19 May 2015 at 00:21, Rowan Collins  wrote:
> Dynamically adjusting the limit would be no help, because if you're that
> hard up against the limit, your only hope is to gracefully end the process 
> anyway.

To be clear - we don't really have hard memory limits in PHP. We have
a limit that users specify in an ini file, but this can be overridden
in a script by just calling ini_set('memory_limit', $moreMemory);. The
only real hard limit is when malloc starts failing, at which point all
hope is lost.


So, I think what would be needed for graceful handling of memory usage is:

* Allow users to specify programmatically (i.e. not in the ini file)
memory trigger limits and a callable for each of those limits.

* When one limit is reached, set the memory limit to the next higher
one, and call the callable associated with the memory level just
reached, at the next appropriate place in the engine. I don't think
checking after each allocation would be feasible as it would be too
nasty to code, as well as having to much of a performance impact.
Instead this seems to be more likely to work if it was tied into the
'tick' functionality.

* When there are no more memory limits left, or a limit would be
higher than memory_limit, trigger the current behaviour for when the
application has run out of memory (i.e. abort the application).

* When gc_collect_cycles is called (and potentially other functions),
at the end of that function check whether the amount of memory being
used is less than reset level for each trigger. If so reduce the
current memory limit to the lowest trigger level.

The reason for having multiple limits is that people will want their
code to do different things at the different limits. For example,
imagine someone who has some PHP code serving a simple API that for
business reasons needs to respond quickly, which uses typically uses
4MB to serve a request.

It would be reasonable for them to have the trigger levels of:

8MB - Log that this request used more memory than average, and someone
should investigate it at some point.

32MB - Log this request is using 8 times as much memory as usual and
someone needs to investigate it reasonably urgently, and trigger
gc_collect_cycles. gc_collect_cycles is a relatively slow function,
and so this will make the request slower than desired.

64MB - Throw an exception and cleanly shut down the application.

And a max memory_limit of 128MB where the application does the current
behaviour of falling over and dying.

I'll wait for some feedback, then write an RFC unless someone can say
something that would be significantly better, or why the above would
be either bad or technically unfeasible.

cheers
Dan

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

[PHP-DEV] Spurious open_basedir warning

[Christoph Becker]

Hello Internals,

there are several bug reports related to open_basedir and non-existant
files/directories.[1]  uramihsayibok's comment on bug #53041 sheds some
light on the issue.  A few weeks ago I had a closer look at it, and it
seems that using expand_filepath_with_mode() instead of
expand_filepath() in php_check_specific_open_basedir() would fix the bug
(see my patch[2]).

I am, however, not sure whether that might have security implications.
Could one of the experienced developers please have a look at the issue?
 Apparently, the spurious open_basedir warning is confusing, and it's
something that is often encountered.

[1] 







[2]


-- 
Christoph M. Becker

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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[Yasuo Ohgaki]

Hi all,

On Sun, May 17, 2015 at 8:44 AM, Levi Morrison  wrote:

> On Sat, May 16, 2015 at 2:17 PM, Rowan Collins 
> wrote:
> > On 16/05/2015 20:15, Levi Morrison wrote:
> >>
> >> The difference is that as time goes on and I've written code for PHP 7
> >> I was hit by this issue. It's an even bigger issue than even I
> >> realized during voting. How many people who voted on that issue have
> >> played with the code from both scenarios? Few, I can't guarantee it
> >> but given the historical precedent it's almost certainly true.
> >
> >
> > Can you give an example of the issue you were hit with? A sample program
> /
> > scenario, where failure to catch an EngineException caused behaviour that
> > was in some way worse than that under PHP 5?
>
> Here's a simplified example that illustrates one issue:
>
> 
> set_error_handler(function(){
> echo "Handled.";
> });
>
> function foo(callable $f) {}
>
> try {
> foo("bar is not callable");
> } catch (Exception $e) {
> echo "Caught.";
> }
>
> echo "Done.", PHP_EOL;
>
> ?>
>
> In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
>
> > Fatal error: Argument 1 passed to foo() must be callable, string given
>
> Note that if the TypeException had been caught by catch (Exception $e)
> the program would have still been correct. This kind of setup exists
> in PHPUnit for example; even if the test has some bad syntax or
> failure the testing harness needs to continue. There are other valid
> uses as well.
>
> The only way to make this work in both PHP 5 and 7 is to modify the
> code, despite the program being 100% correct under PHP 5 and the
> documented semantics.


We should consider internal function error/exception also.
New ZPP raises type error.



produces E_WARNING

Warning: mt_srand() expects parameter 1 to be integer, string given in - on
line 2

If we are going to break codes, it is better to break code consistently.
Is it possible treat each line enclosed by try {}? e.g.



rather than



For example,

set_exception_handler(callback $callback [, bool $single_line_try_block =
FALSE])


Regards,

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