Re: [PHP-DEV] [RFC] Fiber support (again)

[Aaron Piotrowski]

> On Feb 7, 2018, at 7:05 PM, Haitao Lv  wrote:
> 
> Hi internals,
> 
> I propose to introduce the Fiber feature AGAIN.
> 
> The main purpose of the RFC is to introducing a lightweight stackful 
> coroutine support for PHP and make it possible to write non-blocking code in 
> the blocking style.
> 
> In this RFC, no new keyword is needed. So it will not break the PHP 7.3 
> release.
> 
> Please see the RFC https://wiki.php.net/rfc/fiber
> 
> Dmitry and I are working on the implementation at 
> https://github.com/fiberphp/fiber-ext
> And a series of usage demo can be found at 
> https://github.com/fiberphp/fiber-demo
> 
> Please offer you comments.
> 
> Thank you.
> 
> ---
> Haitao Lv
> 


Hi Haitao,

I'm very excited to see this sort of feature coming to PHP.

A couple of questions and thoughts:

- How do you determine when a fiber has returned? Looking at the source, it 
appears Fiber::status() must be used, comparing against constants. Separate 
methods similar to Generator would be better IMO. e.g.: Fiber::alive(), 
Fiber::suspended(), Fiber::running()

- What about throwing exceptions into a fiber?

- Using Fiber::resume() to initialize the fiber and resume feels awkward. 
Separate methods again would be better here, perhaps Fiber::init(...$args) and 
Fiber::resume($send).

- What happens if the sub1() function in the RFC is invoked outside of a fiber?

- I think a keyword here would be beneficial, even if it has a minor BC impact. 
Fibers could then be written like generators. `await` or `emit` as a keyword 
perhaps? This would be a less verbose API, feel less magical (a static method 
call that actually pauses execution feels out of place), and would allow Fibers 
to be returned from methods, named functions, etc with less boilerplate.

Thanks to you and Dmitry for working on this!

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

[PHP-DEV] [RFC] Fiber support (again)

[Haitao Lv]

Hi internals,

I propose to introduce the Fiber feature AGAIN.

The main purpose of the RFC is to introducing a lightweight stackful coroutine 
support for PHP and make it possible to write non-blocking code in the blocking 
style.

In this RFC, no new keyword is needed. So it will not break the PHP 7.3 release.

Please see the RFC https://wiki.php.net/rfc/fiber

Dmitry and I are working on the implementation at 
https://github.com/fiberphp/fiber-ext
And a series of usage demo can be found at 
https://github.com/fiberphp/fiber-demo

Please offer you comments.

Thank you.

---
Haitao Lv


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

Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka. system)libgd

[Christoph M. Becker]

On 07.02.2018 at 21:04, Stanislav Malyshev wrote:

>> bundled libgd)[5].  Another important difference is that our bundled
>> libgd uses ZendMM, but upstream libgd does not[6].
> 
> This one we need to find a solution for. GD is often exposed to the
> unfiltered user input, has a potential to consume large amounts of
> memory and not having ZendMM memory limits in place can be a serious issue.

I fully agree.  Presumably few users are aware of this, and even if they
were, it's not easy to cater to this generally.  Until upstream libgd
adds an API to attach custom memory allocators, we might have to patch
the bundled copy (at least this would be a single, well located
modification, instead of the current mess).

>> For most Linux environments PHP is built with an upstream (system)
>> libgd; on Windows usually the bundled libgd is used.  Users targeting
> 
> Windows is another concern - are there viable solutions for non-bundled
> GD for Windows that we can recommend to the users? If not, that means we
> still have to keep and maintain bundled GD, and if so, there's no point
> to spend any time on un-bundling before we find solution to this.

I don't see a real issue here.  All other external PHP dependencies are
provided by windows.php.net (amongst others, all GD dependencies, such
as libjpeg), so a libgd.dll could also be provided, especially since
upstream already provides a native Windows build "toolchain" which
already relies on the dependencies provided by windows.php.net (see
).

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka. system) libgd

[Stanislav Malyshev]

Hi!

> During the discussion of PR 3080[1] the idea to replace our bundled
> libgd with an (unmodified) upstream libgd[2] has come up again.  It
> seems this issue deserves its own discussion, and probably an RFC.

I think this is a good idea. In general, as open source ecosystem
matures (and more and more people move to use established OSS vendors or
non-OSS vendors well-integrated into OSS system, like macOS/homebrew
setups) most people move to use distributions which supply wide array of
libraries usually covering ones that we used to bundle, and often doing
better job in keeping with updates and security fixes than we can. So in
general I think phasing out bundling, unless absolutely necessary, is
the idea whose time has come.

> bundled libgd)[5].  Another important difference is that our bundled
> libgd uses ZendMM, but upstream libgd does not[6].

This one we need to find a solution for. GD is often exposed to the
unfiltered user input, has a potential to consume large amounts of
memory and not having ZendMM memory limits in place can be a serious issue.

> For most Linux environments PHP is built with an upstream (system)
> libgd; on Windows usually the bundled libgd is used.  Users targeting

Windows is another concern - are there viable solutions for non-bundled
GD for Windows that we can recommend to the users? If not, that means we
still have to keep and maintain bundled GD, and if so, there's no point
to spend any time on un-bundling before we find solution to this.

-- 
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][DISCUSSION] Deprecation of fallback to root scope

[Christoph M. Becker]

On 06.02.2018 at 20:31, Stanislav Malyshev wrote:

>> Do we?  AFAIK, it is not possible to import *all* functions (or even all
>> symbols, for that matter) of a namespace, without explicitly mentioning
>> them.
> 
> We are talking about global namespace aka standard PHP functions, so it
> works out of the box. […]

Ah, I see. :)

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Rowan Collins]

On 7 February 2018 at 16:56, Andrey Andreev  wrote:

> Hi,
>
> What's not obvious (to me at least) here is why is the current
> behavior preventing a ("sensible", as the RFC desribes it)
> implementation of function autoloading? That seems to be a major
> motivation factor for the proposal, yet doesn't seem to be explained
> anywhere.
>


It's not been mentioned explicitly in this thread, but has come up a lot in
previous discussions. I'll attempt to summarise my understanding.

Currently, when you write "foo()" in code marked as namespace "Bob", the
engine does this:

1. Check for a function "Bob\foo", use it if defined
2. Check for a function "foo", use it if defined
3. Raise an error if neither is defined

If we add autoloading of functions, the logical sequence would be to
attempt the autoloader every time we encounter something not defined:

1. Check for a function "Bob\foo", use it if defined
1a. Run autoloader callback for "Bob\foo"; use function if one is now
defined
2. Check for a function "foo", use it if defined
2a. Run autoloader callback for "foo"; use function if one is now defined
3. Raise an error if neither is defined

The problem is that all of this has to happen *every time you call the
function*, because at any time, the function could be registered, or a new
autoloader registered that knows where to find it.

If "foo" is actually a global function, that means steps 1 and 1a will be
run every time your use of "foo()" is reached, meaning that every call has
an additional overhead of calling the autoloader callback.

Since the autoloader callback might in fact be a whole stack of registered
closures, this means a significant overhead every time you mention any
global function, which includes 90% of PHP's standard library.

I hope that clarifies the general problem (and that I haven't made any
mistakes in my explanation).

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Andrey Andreev]

Hi,

What's not obvious (to me at least) here is why is the current
behavior preventing a ("sensible", as the RFC desribes it)
implementation of function autoloading? That seems to be a major
motivation factor for the proposal, yet doesn't seem to be explained
anywhere.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Rowan Collins]

On 7 February 2018 at 15:20, Christoph M. Becker  wrote:

> On 07.02.2018 at 15:02, Rowan Collins wrote:
>
> > - PHP 7.3: Add syntax to explicitly reference functions and constants in
> > the current namespace, such as .\foo or this\foo
>
> It is already possible to use the `namespace` keyword for this, see
> .
>


Huh, I never knew that! Funnily enough, I thought of that as a possibility
(because it's already a reserved word) but rejected it as too long. :P



> > - Slightly uglier syntax.
>
> IMHO, .\foo is very ugly, and namespace\foo is not much better.
>


Yeah; the question is whether that ugliness is something we're willing to
live with for the performance and features it would enable. Most code would
still be less ugly than if we had to prefix all global functions, anyway.

Something worth considering is that even when using namespaced functions,
the shorthand is only available in *exactly the current namespace*, so
you're rather likely to be qualifying or importing them anyway. For
instance, they might be in a child or neighbouring namespace called
"...\functions" or " ...\ utils" or " ...\ streams".

Regards,
-- 
Rowan Collins
[IMSoP]

[PHP-DEV] Replaced the bundled libgd with upstream (aka. system) libgd

[Christoph M. Becker]

Hi everybody!

During the discussion of PR 3080[1] the idea to replace our bundled
libgd with an (unmodified) upstream libgd[2] has come up again.  It
seems this issue deserves its own discussion, and probably an RFC.

Our bundled libgd (particularly as found in master) is mostly compatible
with upstream libgd 2.2.5 – actually, the API is compatible, but there
are several (mostly minor) implementation differences.  For instance,
the $threshold parameter of imagecropauto($im, IMG_CROP_THRESHOLD) is
interpreted differently[3], the result of imagettfbbox() is slightly
different[4] and imagetruecolortopalette() uses a completely different
algorithm if built with libimagequant (which is not available for the
bundled libgd)[5].  Another important difference is that our bundled
libgd uses ZendMM, but upstream libgd does not[6].

For most Linux environments PHP is built with an upstream (system)
libgd; on Windows usually the bundled libgd is used.  Users targeting
both platforms likely already have conditional code (using `GD_BUNDLED`)
to cater to relevant implementation differences.  So, assuming we would
not set `GD_BUNDLED` anymore after bundling upstream libgd, most users
would not notice a difference.  However, the PHP manual explicitly
recommends to use the bundled libgd[7], so users heeding this advice
would face several minor BC breaks.

The main benefit of bundling upstream libgd, though, would be to save
time by avoiding the 2-way synchronizations (which often occur on a per
commit basis, and may even sometimes be overlooked).

Any thoughts are welcome!

[1] 
[2] 
[3] 
[4] 
[5]

[6] 
[7] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Levi Morrison]

On Wed, Feb 7, 2018 at 7:02 AM, Rowan Collins  wrote:
> On 3 February 2018 08:27:18 GMT+00:00, Wes  wrote:
>>Hello PHPeople. I just published the RFC "Deprecation of fallback to
>>root
>>scope".
>>
>>https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
>
>
> Given the discussion so far, how about taking the "opposite" approach:
> deprecate unprefixed reference to functions which *are* in the current
> namespace.
>
> Proposal:
> - PHP 7.3: Add syntax to explicitly reference functions and constants in
> the current namespace, such as .\foo or this\foo
> - PHP 7.4: Raise E_DEPRECATED whenever an unprefixed function/constant
> resolves to something in the current namespace (other than via "use" alias)
> - PHP 8.0: Make all unprefixed functions/constants always refer to the root
> namespace
>
> Pros:
> - Much less disruptive change, as the majority of unprefixed function calls
> are to global functions, and would not need to change.
> - Both cases can be made unambiguous if the author wants to.
> - Apparently OpCache currently mitigates the performance hit by caching
> lookups in a technically unclean way. Users hit by this can make their code
> unambiguous in 7.3, and the optimisation will become clean in 8.0.
> - Function / constant autoloading can be added in 7.x if we accept the
> caveat that unprefixed functions will not be autoloaded; or in 8.0 if we
> want to cover everything.
>
> Cons:
> - Slightly uglier syntax.
> - Still a breaking change (in 8.0).
> - Class names will still be resolved differently from function and constant
> names.
> - Code actively using the fallback system (e.g. tests masking global
> functions with mocks) will need refactoring as there is no way to opt into
> the old behaviour.
> - The .\foo() syntax may appear in similar places to the . concatenation
> operator. Even if technically unambiguous and implementable in the parser,
> this may be confusing to users. A keyword approach like this\foo() would be
> clearer, but more verbose.
>
> What do people think? Is it worth expanding this out into an alternative
> RFC?
>
> Regards,
> --
> Rowan Collins [IMSoP]

My opinion is that the result is both uglier and *even less
consistent* with namespaced types. I'm glad you are at least thinking
about alternative proposals but this is worse than both the original
proposal and doing nothing.

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

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Christoph M. Becker]

On 07.02.2018 at 15:02, Rowan Collins wrote:

> - PHP 7.3: Add syntax to explicitly reference functions and constants in
> the current namespace, such as .\foo or this\foo

It is already possible to use the `namespace` keyword for this, see
.

> - Slightly uglier syntax.

IMHO, .\foo is very ugly, and namespace\foo is not much better.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Rowan Collins]

On 3 February 2018 08:27:18 GMT+00:00, Wes  wrote:
>Hello PHPeople. I just published the RFC "Deprecation of fallback to
>root
>scope".
>
>https://wiki.php.net/rfc/fallback-to-root-scope-deprecation


Given the discussion so far, how about taking the "opposite" approach:
deprecate unprefixed reference to functions which *are* in the current
namespace.

Proposal:
- PHP 7.3: Add syntax to explicitly reference functions and constants in
the current namespace, such as .\foo or this\foo
- PHP 7.4: Raise E_DEPRECATED whenever an unprefixed function/constant
resolves to something in the current namespace (other than via "use" alias)
- PHP 8.0: Make all unprefixed functions/constants always refer to the root
namespace

Pros:
- Much less disruptive change, as the majority of unprefixed function calls
are to global functions, and would not need to change.
- Both cases can be made unambiguous if the author wants to.
- Apparently OpCache currently mitigates the performance hit by caching
lookups in a technically unclean way. Users hit by this can make their code
unambiguous in 7.3, and the optimisation will become clean in 8.0.
- Function / constant autoloading can be added in 7.x if we accept the
caveat that unprefixed functions will not be autoloaded; or in 8.0 if we
want to cover everything.

Cons:
- Slightly uglier syntax.
- Still a breaking change (in 8.0).
- Class names will still be resolved differently from function and constant
names.
- Code actively using the fallback system (e.g. tests masking global
functions with mocks) will need refactoring as there is no way to opt into
the old behaviour.
- The .\foo() syntax may appear in similar places to the . concatenation
operator. Even if technically unambiguous and implementable in the parser,
this may be confusing to users. A keyword approach like this\foo() would be
clearer, but more verbose.

What do people think? Is it worth expanding this out into an alternative
RFC?

Regards,
-- 
Rowan Collins [IMSoP]