[PHP-DEV] Re: [PHP-CVS] com php-src: Missing param in arginfo_pdostatement_setfetchmode: ext/pdo/pdo_stmt.c

[Sebastian Bergmann]

Am 14.02.2019 um 08:13 schrieb Gabriel Caruso:

Commit:ad75511c8e5461cc6ba5cf7aad8f5265615560a8
Author:Gabriel Caruso  Fri, 16 Feb 2018 
21:29:34 -0200
Parents:   d57c56cd6304b92db83180e7939eb6288c3a18af
Branches:  master

Link:   
http://git.php.net/?p=php-src.git;a=commitdiff;h=ad75511c8e5461cc6ba5cf7aad8f5265615560a8

Log:
Missing param in arginfo_pdostatement_setfetchmode

PDO::setFetchMode receives up to 3 params


Are you sure you only want to add this to master (PHP 8) and not (at 
least) also to PHP 7.4?



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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/14/19 3:02 AM, Eugene Leonovich wrote:
> On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan  > wrote:
> 
> On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  > wrote:
>  > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
>  > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s
> (95.1%)
>  > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
>  > > -dopcache.jit=1201): 29.95s (92.7%)
>  >
>  > It may be interesting to try -dopcache.jit=1235. It should JIT
> only hot
>  > functions and requires some warm-up.
> 
> For this use case 1201 was the fastest of all the options I tried
> (including 1235).
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> Here are my results of benchmarking rybakit/msgpack.php:
> 
> bench.php, w/o jit:
>      Total 9.8220 4.3121
> 
> bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
>      Total 8.7255 3.3350
> 
> bench2.php, w/o jit:
>      pure msgpack: 2.2818 sec
>      pure msgpack packed: 2.1717 sec
> 
> bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
>      pure msgpack: 1.5221 sec
>      pure msgpack packed: 1.4739 sec
> 
> Details: https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f

1.3-1.5 times speed-up.
Thanks for benchmarking.

Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Eugene Leonovich]

On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan  wrote:

> On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  wrote:
> > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%)
> > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
> > > -dopcache.jit=1201): 29.95s (92.7%)
> >
> > It may be interesting to try -dopcache.jit=1235. It should JIT only hot
> > functions and requires some warm-up.
>
> For this use case 1201 was the fastest of all the options I tried
> (including 1235).
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Here are my results of benchmarking rybakit/msgpack.php:

bench.php, w/o jit:
Total 9.8220 4.3121

bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
Total 8.7255 3.3350

bench2.php, w/o jit:
pure msgpack: 2.2818 sec
pure msgpack packed: 2.1717 sec

bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
pure msgpack: 1.5221 sec
pure msgpack packed: 1.4739 sec

Details: https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f

-- 
Thank you and best regards,
Eugene Leonovich

[PHP-DEV] Re: proper anonymous classes?

[Christoph M. Becker]

On 13.02.2019 at 09:01, Rasmus Schultz wrote:

> The fact that the anonymous class syntax defines a class *and* immediately
> constructs an instance is quite annoying.
> 
> For one, this is quite incompatible with DI containers' ability to resolve
> constructor arguments.
> 
> Lets say you DI container can register a named component by merely
> referencing a class that uses constructor injection - so lets say this
> works:
> 
> class MyController {
> public function __construct(MyService $service) {
> // ...
> }
> }
> 
> $container->register("my-controller", MyController::class);
> 
> Now I want to register an anonymous class, for example as part of an
> integration test-suite, which is common enough:
> 
> $container->register("my-controller", new class {
> public function __construct(MyService $service) {
> // ...
> }
> });
> 
> This doesn't work, because you're expected to actually pass the constructor
> arguments immediately - because you can only define an anonymous class
> while immediately creating an instance.
> 
> What I really want is just an anonymous class - not an instance, so:
> 
> $container->register("my-controller", class {
> public function __construct(MyService $service) {
> // ...
> }
> });
> 
> The question is, what would a class expression without the new keyword
> evaluate to?
> 
> Since we normally reference classes with just a class-name, I guess I'd
> expect a string, like you'd get from the ::class constant.
> 
> Any hope for something like that?

Not particularly efficient, but likely sufficient for the use case:

  $container->register("my-controller", get_class(new class {
  public function __construct(MyService $service) {
  // ...
  }
  }));

-- 
Christoph M. Becker

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

Re: [PHP-DEV] proper anonymous classes?

[Rasmus Schultz]

It doesn't have to be?

It could just be an inline class expression (without the new keyword) that
evaluates to a string, e.g. a machine-generated class-name?

I don't think that's what first-class support means? e.g. nothing like
constructors in JS or class instances like Dart?

This could just be a "cheap hack" with machine-generated class-names, so we
can reference anonymous classes by name, the same way we reference classes
now.

Introducing classes as instances of some kind of "class class" would be a
more drastic change, since this would not be compatible with existing
string type-hints for class-names. (?)

On Wed, Feb 13, 2019 at 9:16 AM Joe Watkins  wrote:

> What you describe is first class support for classes, nothing much to do
> with anonymous classes.
>
> On Wed, 13 Feb 2019, 09:01 Rasmus Schultz 
>> The fact that the anonymous class syntax defines a class *and* immediately
>> constructs an instance is quite annoying.
>>
>> For one, this is quite incompatible with DI containers' ability to resolve
>> constructor arguments.
>>
>> Lets say you DI container can register a named component by merely
>> referencing a class that uses constructor injection - so lets say this
>> works:
>>
>> class MyController {
>> public function __construct(MyService $service) {
>> // ...
>> }
>> }
>>
>> $container->register("my-controller", MyController::class);
>>
>> Now I want to register an anonymous class, for example as part of an
>> integration test-suite, which is common enough:
>>
>> $container->register("my-controller", new class {
>> public function __construct(MyService $service) {
>> // ...
>> }
>> });
>>
>> This doesn't work, because you're expected to actually pass the
>> constructor
>> arguments immediately - because you can only define an anonymous class
>> while immediately creating an instance.
>>
>> What I really want is just an anonymous class - not an instance, so:
>>
>> $container->register("my-controller", class {
>> public function __construct(MyService $service) {
>> // ...
>> }
>> });
>>
>> The question is, what would a class expression without the new keyword
>> evaluate to?
>>
>> Since we normally reference classes with just a class-name, I guess I'd
>> expect a string, like you'd get from the ::class constant.
>>
>> Any hope for something like that?
>>
>

Re: [PHP-DEV] Drop support for libreadline

[Remi Collet]

Missing links

PHP 8.0 => https://github.com/php/php-src/pull/3823
Drop support for libreadline

PHP 7.x => https://github.com/php/php-src/pull/3824
add readline_list_history with libedit >= 3.1


Remi




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Drop support for libreadline

[Johannes Schlüter]

Hi,

On Mi, 2019-02-13 at 11:56 +0100, Remi Collet wrote:
> Hi,
> 
> 
> Terribly old and known issue.
> 
> libreadline license (GPL) is incompatible with PHP
> 
> We support build with libedit (BSD) for years
> 
> Most Linux distribution use libedit
> Windows also use libedit
> 
> 
> So, this PR is mostly a cleanup of what should have been removed for
> years.
> 


I don't know the size of the patch for this, but as long as we are not
using readline-specific APIs isn't it the user's choice/responsibility
if they happen to link to readline? - As long as that isn't
distributed, but only for their own use it's fine. GPL limits
"redistribution" not "usage"

It is a while since I used libedit last, but in behavior it had notable
differences.

johannes

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

Re: [PHP-DEV] Re: Drop support for libreadline

[Remi Collet]

Le 13/02/2019 à 12:51, Christoph M. Becker a écrit :

> It should be pointed out
> that readline_list_history() doesn't work with libedit, and would be
> completely removed.

This function is available in recent libedit version (3.1+)
So I'm working on a patch to enable it (can also be later added in 7.2+)



Remi



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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was 
extended with few new sections.

Please, consider to review the RFC once again.

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

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation 
improvement itself, at this point. So, ideas are also welcome, but don't 
expect to get them implemented tomorrow.

Thanks. Dmitry.

On 1/31/19 12:43 PM, Dmitry Stogov wrote:
> Hi Internals,
> 
> 
> I'm glad to finally propose including JIT into PHP.
> 
> 
> https://wiki.php.net/rfc/jit
> 
> 
> In the current state it may be included both into PHP-8, where we are 
> going to continue active improvement, and into PHP-7.4, as an 
> experimental feature.
> 
> 
> Thanks. Dmitry.
> 

[PHP-DEV] Re: Drop support for libreadline

[Christoph M. Becker]

On 13.02.2019 at 11:56, Remi Collet wrote:

> Terribly old and known issue.
> 
> libreadline license (GPL) is incompatible with PHP
> 
> We support build with libedit (BSD) for years
> 
> Most Linux distribution use libedit
> Windows also use libedit
> 
> 
> So, this PR is mostly a cleanup of what should have been removed for years.
> 
> 
> Feedback before merge ?

I'm fine with dropping libreadline support, but it should be pointed out
that readline_list_history() doesn't work with libedit, and would be
completely removed.

-- 
Christoph M. Becker

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

[PHP-DEV] Re: [VOTE] Reflection for references

[Nikita Popov]

On Wed, Jan 30, 2019 at 11:07 AM Nikita Popov  wrote:

> Hi internals,
>
> I would like to start the vote on the ReflectionReference RFC:
>
> https://wiki.php.net/rfc/reference_reflection
>
> The vote ends 2019-02-13 and requires a 2/3 majority to pass. Please see
> https://externals.io/message/103738 for the discussion thread.
>

The RFC has passed with 30 votes in favor and one against. The
implementation is merged into PHP 7.4.

Nikita

[PHP-DEV] Drop support for libreadline

[Remi Collet]

Hi,


Terribly old and known issue.

libreadline license (GPL) is incompatible with PHP

We support build with libedit (BSD) for years

Most Linux distribution use libedit
Windows also use libedit


So, this PR is mostly a cleanup of what should have been removed for years.


Feedback before merge ?



Remi

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

[PHP-DEV] Re: ZTS improvement idea

[Dmitry Stogov]

Hi Joe,

On 2/13/19 12:26 PM, Joe Watkins wrote:
> Morning all,
> 
> I'm very pleased to see effort going into this, and the resulting ideas.
> 
> I don't have anything to add about the implementation.
> 
> Since most people are not interested in ZTS, there aren't going to be 
> many voices pushing you to actually make changes, so I want to be that 
> voice.
> 
> The ZTS build is very commonly used in Windows today, and I'm sure 
> everyone doing that would appreciate you making these changes as soon as 
> reasonable, which looks like 7.4, beyond that before we can talk about 
> developing JIT support in Windows, ZTS support must be in place.

There are many things that would be great to get, but with very limited 
forces, we have to set priorities and select the most desired 
functionality, to work on it first.

Thanks. Dmitry.



> 
> Thanks for the effort so far.
> 
> Cheers
> Joe
> 
> On Wed, 13 Feb 2019 at 10:02, Nikita Popov  > wrote:
> 
> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  > wrote:
> 
> Hi,
> 
> 
> After JIT+ZTS related discussion with Joe and Bob, and some
> related analyzes.
> 
> I came to more or less formed design idea and described it at
> https://wiki.php.net/zts-improvement
> 
> This is not an RFC and I'm not sure, if I like to implement TSRM
> changes myself now.
> 
> 
> Comments are welcome.
> 
> 
> Hi Dmitry,
> 
> Thanks for looking into this issue. As a possible alternative I
> would like to suggest the use of ZEND_TLS (__thread) for the
> EG/CG/BG etc globals on Linux (on Windows this is not possible due
> to DLL linkage restrictions). __thread generates very good code
> (single load over %fs segment with constant address) if the global
> is defined and used in an executable. I'm not sure what kind of code
> it generates when TLS is declared in an executable and used in a
> shared object, but as direct access from extensions to the engine
> globals shouldn't be common, it's probably okay even if it uses
> __tls_get_addr.
> 
> Nikita
> 

[PHP-DEV] Re: ZTS improvement idea

[Dmitry Stogov]

Hi Nikita,


On 2/13/19 12:02 PM, Nikita Popov wrote:
> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  > wrote:
> 
> Hi,
> 
> 
> After JIT+ZTS related discussion with Joe and Bob, and some related
> analyzes.
> 
> I came to more or less formed design idea and described it at
> https://wiki.php.net/zts-improvement
> 
> This is not an RFC and I'm not sure, if I like to implement TSRM
> changes myself now.
> 
> 
> Comments are welcome.
> 
> 
> Hi Dmitry,
> 
> Thanks for looking into this issue. As a possible alternative I would 
> like to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc 
> globals on Linux (on Windows this is not possible due to DLL linkage 
> restrictions).

I played with __thread long time ago (may be 10 years), and that time it 
didn't work as expected. I can't remember the exact problems. May be it 
made troubles when used in DSO PHP build with DSO extensions, may be the 
size of "__thread" segment was limited, may be both.

> __thread generates very good code (single load over %fs 
> segment with constant address) if the global is defined and used in an 
> executable.

I suppose 2 loads:

movqexecutor_globals@gottpoff(%rip), %rax
movq%fs:field_offset(%rax), %rax

> I'm not sure what kind of code it generates when TLS is 
> declared in an executable and used in a shared object, but as direct 
> access from extensions to the engine globals shouldn't be common, it's 
> probably okay even if it uses __tls_get_addr.

The main problem with "__thread" might be portability.
I especially thought about keeping TSRM layer with the same API, to 
avoid portability issues, but if "__thread" works fine, we definitely 
should use it.

On the other hand, I'm not sure, who uses ZTS build today and if they 
need performance.

Thanks. Dmitry.


> 
> Nikita

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

[PHP-DEV] Re: ZTS improvement idea

[Joe Watkins]

Morning all,

I'm very pleased to see effort going into this, and the resulting ideas.

I don't have anything to add about the implementation.

Since most people are not interested in ZTS, there aren't going to be many
voices pushing you to actually make changes, so I want to be that voice.

The ZTS build is very commonly used in Windows today, and I'm sure everyone
doing that would appreciate you making these changes as soon as reasonable,
which looks like 7.4, beyond that before we can talk about developing JIT
support in Windows, ZTS support must be in place.

Thanks for the effort so far.

Cheers
Joe

On Wed, 13 Feb 2019 at 10:02, Nikita Popov  wrote:

> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  wrote:
>
>> Hi,
>>
>>
>> After JIT+ZTS related discussion with Joe and Bob, and some related
>> analyzes.
>>
>> I came to more or less formed design idea and described it at
>> https://wiki.php.net/zts-improvement
>>
>> This is not an RFC and I'm not sure, if I like to implement TSRM changes
>> myself now.
>>
>>
>> Comments are welcome.
>>
>
> Hi Dmitry,
>
> Thanks for looking into this issue. As a possible alternative I would like
> to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on
> Linux (on Windows this is not possible due to DLL linkage restrictions).
> __thread generates very good code (single load over %fs segment with
> constant address) if the global is defined and used in an executable. I'm
> not sure what kind of code it generates when TLS is declared in an
> executable and used in a shared object, but as direct access from
> extensions to the engine globals shouldn't be common, it's probably okay
> even if it uses __tls_get_addr.
>
> Nikita
>

[PHP-DEV] Re: ZTS improvement idea

[Nikita Popov]

On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  wrote:

> Hi,
>
>
> After JIT+ZTS related discussion with Joe and Bob, and some related
> analyzes.
>
> I came to more or less formed design idea and described it at
> https://wiki.php.net/zts-improvement
>
> This is not an RFC and I'm not sure, if I like to implement TSRM changes
> myself now.
>
>
> Comments are welcome.
>

Hi Dmitry,

Thanks for looking into this issue. As a possible alternative I would like
to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on
Linux (on Windows this is not possible due to DLL linkage restrictions).
__thread generates very good code (single load over %fs segment with
constant address) if the global is defined and used in an executable. I'm
not sure what kind of code it generates when TLS is declared in an
executable and used in a shared object, but as direct access from
extensions to the engine globals shouldn't be common, it's probably okay
even if it uses __tls_get_addr.

Nikita

[PHP-DEV] ZTS improvement idea

[Dmitry Stogov]

Hi,


After JIT+ZTS related discussion with Joe and Bob, and some related analyzes.

I came to more or less formed design idea and described it at 
https://wiki.php.net/zts-improvement

This is not an RFC and I'm not sure, if I like to implement TSRM changes myself 
now.


Comments are welcome.


Thanks. Dmitry.

Re: [PHP-DEV] proper anonymous classes?

[Joe Watkins]

What you describe is first class support for classes, nothing much to do
with anonymous classes.

On Wed, 13 Feb 2019, 09:01 Rasmus Schultz  The fact that the anonymous class syntax defines a class *and* immediately
> constructs an instance is quite annoying.
>
> For one, this is quite incompatible with DI containers' ability to resolve
> constructor arguments.
>
> Lets say you DI container can register a named component by merely
> referencing a class that uses constructor injection - so lets say this
> works:
>
> class MyController {
> public function __construct(MyService $service) {
> // ...
> }
> }
>
> $container->register("my-controller", MyController::class);
>
> Now I want to register an anonymous class, for example as part of an
> integration test-suite, which is common enough:
>
> $container->register("my-controller", new class {
> public function __construct(MyService $service) {
> // ...
> }
> });
>
> This doesn't work, because you're expected to actually pass the constructor
> arguments immediately - because you can only define an anonymous class
> while immediately creating an instance.
>
> What I really want is just an anonymous class - not an instance, so:
>
> $container->register("my-controller", class {
> public function __construct(MyService $service) {
> // ...
> }
> });
>
> The question is, what would a class expression without the new keyword
> evaluate to?
>
> Since we normally reference classes with just a class-name, I guess I'd
> expect a string, like you'd get from the ::class constant.
>
> Any hope for something like that?
>

[PHP-DEV] proper anonymous classes?

[Rasmus Schultz]

The fact that the anonymous class syntax defines a class *and* immediately
constructs an instance is quite annoying.

For one, this is quite incompatible with DI containers' ability to resolve
constructor arguments.

Lets say you DI container can register a named component by merely
referencing a class that uses constructor injection - so lets say this
works:

class MyController {
public function __construct(MyService $service) {
// ...
}
}

$container->register("my-controller", MyController::class);

Now I want to register an anonymous class, for example as part of an
integration test-suite, which is common enough:

$container->register("my-controller", new class {
public function __construct(MyService $service) {
// ...
}
});

This doesn't work, because you're expected to actually pass the constructor
arguments immediately - because you can only define an anonymous class
while immediately creating an instance.

What I really want is just an anonymous class - not an instance, so:

$container->register("my-controller", class {
public function __construct(MyService $service) {
// ...
}
});

The question is, what would a class expression without the new keyword
evaluate to?

Since we normally reference classes with just a class-name, I guess I'd
expect a string, like you'd get from the ::class constant.

Any hope for something like that?