Re: [PHP-DEV] RE: Requesting php-src Karma

[Thomas Punt]

Thank you Peter, Anatol, and Kalle!

> Thomas, please check https://wiki.php.net/vcs/gitworkflow and ask if there's 
> something to be cleared out.

Thanks for the link - I'll be sure to ask if there is anything that's not clear.

Regards,
Tom

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Richard Jennings]

In my opinion this suggestion reduces readability and increases cognative
burden and as such I hope it is not included. Regards

On Fri, 26 Jan 2018 at 21:52, Fleshgrinder  wrote:

> On 1/26/2018 7:16 PM, Christian Schneider wrote:
> > Hi there,
> > I have a proposal for a shorthand notation of associative arrays
> borrowed from another language:
> >   :$foo
> > would be equivalent to
> >   'foo' => $foo
> > and would work with array, list or []
> >
> > Motivation behind it, maybe someone else finds more good uses:
> >
> > 1) Emulating named parameters with associative arrays like
> >   html::img([ 'src' => $src, 'alt' => $alt ]);
> >could be written as
> >   html::img([ :$src, :$alt ]);
> >which encourages consistent naming of variables and parameters
> >
> > 2) Simplifying list destructuring with non-integer keys, example taking
> from
> http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list
> >   foreach ($data as ["id" => $id, "name" => $name]) {
> >becomes
> >   foreach ($data as [ :$id, :$name ]) {
> >which reduces redundancy.
> >
> > I implemented a minimal patch (2 lines are added to the parser) to
> implement this which you can find at
> >   https://cschneid.com/php/php7_2/assoc_array_shorthand.patch
> >
> > What do you think, is this worth an RFC? I hope I didn't miss an
> existing one :-)
> >
> > Regards,
> > - Chris
> >
> >
>
> Hi Chris!
>
> I really like this proposal. `compact` is cumbersome to use, or lets
> say, almost impossible without an intelligent IDE. However, what is more
> important is the fact that is would allow for a very readable and usable
> approach for destructuring of associative arrays (as illustrated by your
> example) which is very, very neat. The change is also extremely minimal
> which speaks for it.
>
> I would support you in writing up an RFC for this (if desired).
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Richard Jennings
Jennings Technology Limited
Company Number: 09827512
VAT Number: 224 8864 84

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Fleshgrinder]

On 1/26/2018 7:16 PM, Christian Schneider wrote:
> Hi there,
> I have a proposal for a shorthand notation of associative arrays borrowed 
> from another language:
>   :$foo
> would be equivalent to
>   'foo' => $foo
> and would work with array, list or []
> 
> Motivation behind it, maybe someone else finds more good uses:
> 
> 1) Emulating named parameters with associative arrays like
>   html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
>   html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters
> 
> 2) Simplifying list destructuring with non-integer keys, example taking from 
> http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list
>   foreach ($data as ["id" => $id, "name" => $name]) {
>becomes
>   foreach ($data as [ :$id, :$name ]) {
>which reduces redundancy.
> 
> I implemented a minimal patch (2 lines are added to the parser) to implement 
> this which you can find at
>   https://cschneid.com/php/php7_2/assoc_array_shorthand.patch
> 
> What do you think, is this worth an RFC? I hope I didn't miss an existing one 
> :-)
> 
> Regards,
> - Chris
> 
> 

Hi Chris!

I really like this proposal. `compact` is cumbersome to use, or lets
say, almost impossible without an intelligent IDE. However, what is more
important is the fact that is would allow for a very readable and usable
approach for destructuring of associative arrays (as illustrated by your
example) which is very, very neat. The change is also extremely minimal
which speaks for it.

I would support you in writing up an RFC for this (if desired).

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Shorthand proposal for associative arrays

[David Rodrigues]

Sorry. I mean "compact()" instead of extract() (it basically does the
oposite hehe), I confused everything in a hurry. Sorry.

So the real example is: html::img(compact('src', 'alt'));

2018-01-26 19:39 GMT-02:00 Michael Morris :

> Forgot something in the previous post...
>
> On Fri, Jan 26, 2018 at 12:16 PM, Christian Schneider <
> cschn...@cschneid.com
> > wrote:
>
> > Hi there,
> > I have a proposal for a shorthand notation of associative arrays borrowed
> > from another language:
> > :$foo
> > would be equivalent to
> > 'foo' => $foo
> > and would work with array, list or []
> >
> > Motivation behind it, maybe someone else finds more good uses:
> >
> > 1) Emulating named parameters with associative arrays like
> > html::img([ 'src' => $src, 'alt' => $alt ]);
> >could be written as
> > html::img([ :$src, :$alt ]);
> >which encourages consistent naming of variables and parameters
> >
>
> The most similar extant feature to this is compact, but it's not as compact
> as this syntax.
>
> $src = 'my.jpg';
> $alt = 'My alt';
> html::img(compact($src, $alt));
>
> will accomplish the same thing since compact does the reverse of extract -
> it pulls the specified variables from the local scope and puts them into an
> associative array.
>



-- 
David Rodrigues

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Michael Morris]

Forgot something in the previous post...

On Fri, Jan 26, 2018 at 12:16 PM, Christian Schneider  wrote:

> Hi there,
> I have a proposal for a shorthand notation of associative arrays borrowed
> from another language:
> :$foo
> would be equivalent to
> 'foo' => $foo
> and would work with array, list or []
>
> Motivation behind it, maybe someone else finds more good uses:
>
> 1) Emulating named parameters with associative arrays like
> html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
> html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters
>

The most similar extant feature to this is compact, but it's not as compact
as this syntax.

$src = 'my.jpg';
$alt = 'My alt';
html::img(compact($src, $alt));

will accomplish the same thing since compact does the reverse of extract -
it pulls the specified variables from the local scope and puts them into an
associative array.

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Michael Morris]

On Fri, Jan 26, 2018 at 2:00 PM, David Rodrigues 
wrote:

> Maybe you should see the extract() method.


Uhm, what? You need to learn what extract does before you recommend it as
an alternative to someone's proposal.  Extract takes an array and moves
their keys onto the local symbol table. So

extract( ['src' => 'myimg.jpg', 'alt' => 'My alt']);
echo $src; // myimg.jpg
echo $alt; // My alt

Using extract on an array with numeric keys gives you fun stuff like $0, $1
and so on.  Extract sees most of its use in PHP based template management
classes where an associative array is extracted than a template file is
included, to allow the template file to use the key names as variables
rather than the array syntax.

As to the proposal itself.

> Motivation behind it, maybe someone else finds more good uses:
>
> 1) Emulating named parameters with associative arrays like
> html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
> html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters

I've been mulling this over since I saw it earlier today.  It's kinda neat
to be honest.

RE: [PHP-DEV] RE: Requesting php-src Karma

[Anatol Belski]

> -Original Message-
> From: Peter Cowburn [mailto:petercowb...@gmail.com]
> Sent: Friday, January 26, 2018 9:16 PM
> To: Anatol Belski 
> Cc: Thomas Punt ; PHP internals list
> 
> Subject: Re: [PHP-DEV] RE: Requesting php-src Karma
> 
> 
> 
> On 26 January 2018 at 20:02, Anatol Belski 
> > wrote:
> 
> 
>   Hi,
> 
>   > -Original Message-
>   > From: Thomas Punt [mailto:tp...@hotmail.co.uk
>  ]
>   > Sent: Thursday, January 25, 2018 11:41 PM
>   > To: PHP internals list   >
>   > Subject: [PHP-DEV] Requesting php-src Karma
>   >
>   > Hi internals,
>   >
>   >
>   > I'd like to request for php-src karma for my account (tpunt) in order 
> to
> help
>   >
>   > with the handling of PRs on GitHub. Having been contributing to PHP
> for
>   >
>   > a few years now, I feel like I've got the hang of things well enough 
> to
> make
>   >
>   > more of an impact to the project now.
>   >
>   I've first seen Thomas' contributions over two years ago at his early
> efforts to document PHP 7.0 features. At least from that point on, he made
> contribution to both doc and the core codebase through various pull requests
> and reviews. Based on his continuous and prudent participation, I'd see it as
> adequate to provide Thomas with the direct access to php-src. He is a valuable
> PHP contributor in point of fact.
> 
> 
> 
> Seconded. Thomas is a valuable contributor to PHP and I'm more than happy to
> bump his commit karma to include php-src (and, indeed, have done so [1]).
> Thomas, thank you for your involvement in the project so far!
> 
Thanks, Peter! You're fast 

Thomas, please check https://wiki.php.net/vcs/gitworkflow and ask if there's 
something to be cleared out.

Regards

Anatol

Re: [PHP-DEV] RE: Requesting php-src Karma

[Peter Cowburn]

On 26 January 2018 at 20:02, Anatol Belski  wrote:

> Hi,
>
> > -Original Message-
> > From: Thomas Punt [mailto:tp...@hotmail.co.uk]
> > Sent: Thursday, January 25, 2018 11:41 PM
> > To: PHP internals list 
> > Subject: [PHP-DEV] Requesting php-src Karma
> >
> > Hi internals,
> >
> >
> > I'd like to request for php-src karma for my account (tpunt) in order to
> help
> >
> > with the handling of PRs on GitHub. Having been contributing to PHP for
> >
> > a few years now, I feel like I've got the hang of things well enough to
> make
> >
> > more of an impact to the project now.
> >
> I've first seen Thomas' contributions over two years ago at his early
> efforts to document PHP 7.0 features. At least from that point on, he made
> contribution to both doc and the core codebase through various pull
> requests and reviews. Based on his continuous and prudent participation,
> I'd see it as adequate to provide Thomas with the direct access to php-src.
> He is a valuable PHP contributor in point of fact.
>

Seconded. Thomas is a valuable contributor to PHP and I'm more than happy
to bump his commit karma to include php-src (and, indeed, have done so [1]).
Thomas, thank you for your involvement in the project so far!

[1] http://svn.php.net/viewvc?view=revision=343955


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

Re: [PHP-DEV] RE: Requesting php-src Karma

[Kalle Sommer Nielsen]

On 26 Jan 2018 21.02 <20%2018%2021%2002>, "Anatol Belski" 
wrote:

Hi,

> -Original Message-
> From: Thomas Punt [mailto:tp...@hotmail.co.uk]
> Sent: Thursday, January 25, 2018 11:41 PM
> To: PHP internals list 
> Subject: [PHP-DEV] Requesting php-src Karma
>
> Hi internals,
>
>
> I'd like to request for php-src karma for my account (tpunt) in order to
help
>
> with the handling of PRs on GitHub. Having been contributing to PHP for
>
> a few years now, I feel like I've got the hang of things well enough to
make
>
> more of an impact to the project now.
>
I've first seen Thomas' contributions over two years ago at his early
efforts to document PHP 7.0 features. At least from that point on, he made
contribution to both doc and the core codebase through various pull
requests and reviews. Based on his continuous and prudent participation,
I'd see it as adequate to provide Thomas with the direct access to php-src.
He is a valuable PHP contributor in point of fact.

Regards




Anatol

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

[PHP-DEV] RE: Requesting php-src Karma

[Anatol Belski]

Hi,

> -Original Message-
> From: Thomas Punt [mailto:tp...@hotmail.co.uk]
> Sent: Thursday, January 25, 2018 11:41 PM
> To: PHP internals list 
> Subject: [PHP-DEV] Requesting php-src Karma
> 
> Hi internals,
> 
> 
> I'd like to request for php-src karma for my account (tpunt) in order to help
> 
> with the handling of PRs on GitHub. Having been contributing to PHP for
> 
> a few years now, I feel like I've got the hang of things well enough to make
> 
> more of an impact to the project now.
> 
I've first seen Thomas' contributions over two years ago at his early efforts 
to document PHP 7.0 features. At least from that point on, he made contribution 
to both doc and the core codebase through various pull requests and reviews. 
Based on his continuous and prudent participation, I'd see it as adequate to 
provide Thomas with the direct access to php-src. He is a valuable PHP 
contributor in point of fact. 

Regards

Anatol

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

Re: [PHP-DEV] Shorthand proposal for associative arrays

[David Rodrigues]

Sorry, the extract() function will receives an array as first argument.

html::img(extract(['src', 'alt']);

2018-01-26 18:00 GMT-02:00 David Rodrigues :

> Maybe you should see the extract() method. It will receive strings as
> varargs and will create an associative array with the string name and the
> value, similar to your first example.
>
> html::img(extract('src', 'alt'));
>
>
> 2018-01-26 16:16 GMT-02:00 Christian Schneider :
>
>> Hi there,
>> I have a proposal for a shorthand notation of associative arrays borrowed
>> from another language:
>> :$foo
>> would be equivalent to
>> 'foo' => $foo
>> and would work with array, list or []
>>
>> Motivation behind it, maybe someone else finds more good uses:
>>
>> 1) Emulating named parameters with associative arrays like
>> html::img([ 'src' => $src, 'alt' => $alt ]);
>>could be written as
>> html::img([ :$src, :$alt ]);
>>which encourages consistent naming of variables and parameters
>>
>> 2) Simplifying list destructuring with non-integer keys, example taking
>> from http://php.net/manual/en/migration71.new-features.php#migrat
>> ion71.new-features.support-for-keys-in-list
>> foreach ($data as ["id" => $id, "name" => $name]) {
>>becomes
>> foreach ($data as [ :$id, :$name ]) {
>>which reduces redundancy.
>>
>> I implemented a minimal patch (2 lines are added to the parser) to
>> implement this which you can find at
>> https://cschneid.com/php/php7_2/assoc_array_shorthand.patch
>>
>> What do you think, is this worth an RFC? I hope I didn't miss an existing
>> one :-)
>>
>> Regards,
>> - Chris
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> David Rodrigues
>



-- 
David Rodrigues

Re: [PHP-DEV] Shorthand proposal for associative arrays

[David Rodrigues]

Maybe you should see the extract() method. It will receive strings as
varargs and will create an associative array with the string name and the
value, similar to your first example.

html::img(extract('src', 'alt'));


2018-01-26 16:16 GMT-02:00 Christian Schneider :

> Hi there,
> I have a proposal for a shorthand notation of associative arrays borrowed
> from another language:
> :$foo
> would be equivalent to
> 'foo' => $foo
> and would work with array, list or []
>
> Motivation behind it, maybe someone else finds more good uses:
>
> 1) Emulating named parameters with associative arrays like
> html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
> html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters
>
> 2) Simplifying list destructuring with non-integer keys, example taking
> from http://php.net/manual/en/migration71.new-features.php#
> migration71.new-features.support-for-keys-in-list
> foreach ($data as ["id" => $id, "name" => $name]) {
>becomes
> foreach ($data as [ :$id, :$name ]) {
>which reduces redundancy.
>
> I implemented a minimal patch (2 lines are added to the parser) to
> implement this which you can find at
> https://cschneid.com/php/php7_2/assoc_array_shorthand.patch
>
> What do you think, is this worth an RFC? I hope I didn't miss an existing
> one :-)
>
> Regards,
> - Chris
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
David Rodrigues

Re: [PHP-DEV] return values of socket_recvmsg

[Sam Ding]

The return data in PHP is "$data" which is an array with 4 elements,
does it match to "zmsg" inside of c function
"socket_recvmsg"(/home/work/php/php/ext/sockets/sendrecvmsg.c:214)?

Here zmsg is struct with:

(gdb) ptype zmsg
type = struct _zval_struct {
zend_value value;
union {
struct {...} v;
uint32_t type_info;
} u1;
union {
uint32_t next;
uint32_t cache_slot;
uint32_t lineno;
uint32_t num_args;
uint32_t fe_pos;
uint32_t fe_iter_idx;
uint32_t access_flags;
uint32_t property_guard;
uint32_t extra;
} u2;
} *

How do these two variables match between php and C?

Thanks,

Sam

Sam Ding/Toronto/IBM wrote on 01/26/2018 09:36:00 AM:

> From: Sam Ding/Toronto/IBM
> To: Kalle Sommer Nielsen 
> Cc: PHP internals , kalle@gmail.com
> Date: 01/26/2018 09:36 AM
> Subject: Re: [PHP-DEV] return values of socket_recvmsg
>
> Thank Kalle,
>
> I knew the implementaion of socket_recvmsg(), but want to know the
> return data structure.
> The test on Big_endian (s390x) got a little different return result
> than on x86_64, try to dig out
> where the problem is.
>
> Thanks,
>
> Sam
>
>
> kalle@gmail.com wrote on 01/26/2018 01:58:23 AM:
>
> > From: Kalle Sommer Nielsen 
> > To: Sam Ding 
> > Cc: PHP internals 
> > Date: 01/26/2018 01:58 AM
> > Subject: Re: [PHP-DEV] return values of socket_recvmsg
> > Sent by: kalle@gmail.com
> >
> > Hi Sam
> >
> > 2018-01-25 23:11 GMT+01:00 Sam Ding :
> > >
> > > The test case  ext/sockets/tests/socket_recvmsg.php  has following
output
> > > on x86_64:
> > >
> > > ===
> > > ...
> > > 1 Array
> > > 2 (
> > > 3[name] => Array
> > > 4(
> > > 5[family] => 10
> > > 6[addr] => ::1
> > > 7[port] => 7001
> > > 8[flowinfo] => 0
> > > 9[scope_id] => 0
> > > 10)
> > > 11
> > > 12[control] => Array
> > > 13   (
> > > 14[0] => Array
> > > 15   (
> > > 16[level] => 41
> > > 17[type] => 50
> > > 18[data] => Array
> > > 19   (
> > > 20[addr] => ::1
> > > 21[ifindex] => 1
> > > 22)
> > > 23)
> > > 24)
> > > ...
> > > ===
> > > This is output  by c
> > > function:"socket_recvmsg"(/home/work/php/php/ext/sockets/
> sendrecvmsg.c:214),
> >
> > You can find the implementation of socket_recvmsg() in the ext/sockets
> > directory here:
> > https://urldefense.proofpoint.com/v2/url?
> >
>
u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3Dext_sockets_sendrecvmsg.c-3Bh-3D7b9c4e8ad357b73b514dc5feb8dc8d9ca215126b-3Bhb-3DHEAD-23l210=DwIBaQ=jf_iaSHvJObTbx-

> > siA1ZOg=CBZ1IFMUPf-s4Wt-
> >
>
elABGKFWisr3DNfFfWYNaKkXXUE=f8KTE9WyceLmQxKXG77FBkDIVqCnJ54BBnXEQuSQCo4=GOFChuk86IBBBORDL3I50gHrzmF4kTmYkq1qCeMufBQ=

> >
> >
> >
> > --
> > regards,
> >
> > Kalle Sommer Nielsen
> > ka...@php.net
> >

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Larry Garfield]

On Friday, January 26, 2018 8:43:20 AM CST Christoph M. Becker wrote:
> On 26.01.2018 at 00:28, Larry Garfield wrote:
> > On the read side (which you'd want for a generator or similar), the logic
> > you'd want is essentially:
> > 
> > class Ints extends ArrayObject {
> > 
> > public function current() : int {
> > 
> > return parent::current();
> > 
> > }
> > 
> > }
> > 
> > Which lints fine, but when I tested it just now returns strings quite
> > happily without a type error, which seems wrong to me.  (Why is it doing
> > that, and is it a bug?)
> 
> ArrayObject does not have a `current` method[1] (it does not implement
> Iterator, but rather IteratorAggregate), so it is never called, and
> therefore the `parent::current()` call doesn't error, from what I can tell.
> 
> For what it's worth, overriding the `offsetGet` method works as expected[2].
> 
> [1] 
> [2] 

Well that would explain it.  I had tried offsetGet() as well, but realized 
after reading this that I just flat out fatfingered it. Ah well.

Still, the rest of my post still applies.

--Larry Garfield


signature.asc
Description: This is a digitally signed message part.

[PHP-DEV] Shorthand proposal for associative arrays

[Christian Schneider]

Hi there,
I have a proposal for a shorthand notation of associative arrays borrowed from 
another language:
:$foo
would be equivalent to
'foo' => $foo
and would work with array, list or []

Motivation behind it, maybe someone else finds more good uses:

1) Emulating named parameters with associative arrays like
html::img([ 'src' => $src, 'alt' => $alt ]);
   could be written as
html::img([ :$src, :$alt ]);
   which encourages consistent naming of variables and parameters

2) Simplifying list destructuring with non-integer keys, example taking from 
http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list
foreach ($data as ["id" => $id, "name" => $name]) {
   becomes
foreach ($data as [ :$id, :$name ]) {
   which reduces redundancy.

I implemented a minimal patch (2 lines are added to the parser) to implement 
this which you can find at
https://cschneid.com/php/php7_2/assoc_array_shorthand.patch

What do you think, is this worth an RFC? I hope I didn't miss an existing one 
:-)

Regards,
- Chris


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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Rowan Collins]

On 26 January 2018 at 14:20, Michael Morris  wrote:

> On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller  wrote:
> >> >> $b instanceof SomeClass
> >> >>
> >> >> Returns true if SomeClass can be iterated and contains only strings.
> >> >>
> >> >
> >> > This would block generics with that syntax then.
> >> >
> >>
> >> I don't understand this comment.
> >>
> >
> > You restrict these type parameters to iterators, but generics are useful
> > in a lot more places.
> >
>
> iterABLE --- not iterATOR.  Two different things.
>
> [...]
>
> The similarity of the names is regrettable, but it's already in place and
> can't be changed at this point.
>


I think you misunderstood Niklas's point. Your example showed the syntax
"SomeClass" with an iterator/iterable specific meaning, which would
mean we couldn't later use this syntax for generics. With generics, "$b
instanceof SomeClass" would mean "is the class of $b, or one of its
parents or interfaces, a generic template SomeClass specialised on the
type string"; that would be incompatible with your proposed meaning of "$b can
be iterated and contains only strings".

The plain form "iterable" would co-exist fine with generics, and
"Iterator" could be kept compatible if a generic interface
"Iterator" was added when generics came along, so we wouldn't be tying
our hands by adding those.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] return values of socket_recvmsg

[Sam Ding]

Thank Kalle,

I knew the implementaion of socket_recvmsg(), but want to know the return
data structure.
The test on Big_endian (s390x) got a little different return result than on
x86_64, try to dig out
where the problem is.

Thanks,

Sam


kalle@gmail.com wrote on 01/26/2018 01:58:23 AM:

> From: Kalle Sommer Nielsen 
> To: Sam Ding 
> Cc: PHP internals 
> Date: 01/26/2018 01:58 AM
> Subject: Re: [PHP-DEV] return values of socket_recvmsg
> Sent by: kalle@gmail.com
>
> Hi Sam
>
> 2018-01-25 23:11 GMT+01:00 Sam Ding :
> >
> > The test case  ext/sockets/tests/socket_recvmsg.php  has following
output
> > on x86_64:
> >
> > ===
> > ...
> > 1 Array
> > 2 (
> > 3[name] => Array
> > 4(
> > 5[family] => 10
> > 6[addr] => ::1
> > 7[port] => 7001
> > 8[flowinfo] => 0
> > 9[scope_id] => 0
> > 10)
> > 11
> > 12[control] => Array
> > 13   (
> > 14[0] => Array
> > 15   (
> > 16[level] => 41
> > 17[type] => 50
> > 18[data] => Array
> > 19   (
> > 20[addr] => ::1
> > 21[ifindex] => 1
> > 22)
> > 23)
> > 24)
> > ...
> > ===
> > This is output  by c
> >
function:"socket_recvmsg"(/home/work/php/php/ext/sockets/sendrecvmsg.c:214),

>
> You can find the implementation of socket_recvmsg() in the ext/sockets
> directory here:
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3Dext_sockets_sendrecvmsg.c-3Bh-3D7b9c4e8ad357b73b514dc5feb8dc8d9ca215126b-3Bhb-3DHEAD-23l210=DwIBaQ=jf_iaSHvJObTbx-

> siA1ZOg=CBZ1IFMUPf-s4Wt-
>
elABGKFWisr3DNfFfWYNaKkXXUE=f8KTE9WyceLmQxKXG77FBkDIVqCnJ54BBnXEQuSQCo4=GOFChuk86IBBBORDL3I50gHrzmF4kTmYkq1qCeMufBQ=

>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Christoph M. Becker]

On 26.01.2018 at 00:28, Larry Garfield wrote:

> On the read side (which you'd want for a generator or similar), the logic 
> you'd want is essentially:
> 
> class Ints extends ArrayObject {
> public function current() : int {
> return parent::current();
> }
> }
> 
> Which lints fine, but when I tested it just now returns strings quite happily 
> without a type error, which seems wrong to me.  (Why is it doing that, and is 
> it a bug?)

ArrayObject does not have a `current` method[1] (it does not implement
Iterator, but rather IteratorAggregate), so it is never called, and
therefore the `parent::current()` call doesn't error, from what I can tell.

For what it's worth, overriding the `offsetGet` method works as expected[2].

[1] 
[2] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller  wrote:

> Michael Morris  schrieb am Fr., 26. Jan. 2018, 02:06:
>
>> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller  wrote:
>>
>> >
>> >>
>> >> $a instanceof array
>> >>
>> >
>> > That might work, but array should only return true if it's an
>> > array, not for anything that implements ArrayAccess.
>> >
>> >
>>
>> Related:
>>
>> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
>>
>> >
>> >
>> > I see no value to this operator being applied to non-array
>> > traversables.
>>
>>
>> If an array access object can't masquerade as an array it loses some of
>> its
>> value, but Niklas is right - it is important to distinguish such objects
>> from native arrays.  One solution would be to promote "iterable" to
>> keyword
>> status.  The flexibility to take any iterable will be needed I think.
>>
>> $a instanceof iterable
>>
>> Would return true for anything iterable (which we can already test with
>> is_iterable() ) where all values where strings.
>>
>> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
>> >
>> > Our iterators cannot always be reliably rewound, such as
>> > when using generators. Checking that the generator returns only
>> > strings would consume all the input and would therefore be useless.
>>
>>
>> True - I hadn't thought of those. But as of PHP 7 generators can type
>> declare their return value.
>
>
> They can only define generator as return type, which is what they return
> when you call a generator function.
>
> Even if you could declare the return type of the generator, you'd still
> have the same problem with the yielded values.
>

See my comment about coding around morons being a pointless exercise.  You
throw an error and force the moron to fix their code.


>
> So, given `$a instanceof iterable`, if
>> $a is a reference to a generator, then the engine could check the return
>> type declaration and only give true on a match without attempting to use
>> the generator.
>>
>> We can follow this pattern farther - The return of an
>> ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
>> instanceof rather than actually pulling data from these methods.
>>
>> We are having the return rely on the promise of the code, but in each case
>> TypeError would be raised anyway if it breaks it's promise to instanceof
>> so
>> errors aren't being avoided.
>>
>>
>>
>> > Returns true if $a is an array (or implements array access) and that all
>> >> it's members are strings.
>> >>
>> >> $b instanceof SomeClass
>> >>
>> >> Returns true if SomeClass can be iterated and contains only strings.
>> >>
>> >
>> > This would block generics with that syntax then.
>> >
>>
>> I don't understand this comment.
>>
>
> You restrict these type parameters to iterators, but generics are useful
> in a lot more places.
>

iterABLE --- not iterOR.  Two different things.

Iterable is a psuedotype in PHP covering anything that can be traversed
with foreach, including std_class, which is what I think what you mean by
generator.  There's even an existing function, is_iterable() to detect
them. `$a instanceof iterable` will return the same as `is_iterable($a);`

Generics specifically are already detectable by `$a instanceof stdClass`
`$a instanceof Iterator` detected that interface, but not arrays and
generics.
`$a instanceof iterable` would detect all three.

The similarity of the names is regrettable, but it's already in place and
can't be changed at this point.

Re: [PHP-DEV] threadsafe php crashes too easily

[Hajo Locke]

Hello,

thank you all for your suggestions.

Am 26.01.2018 um 13:21 schrieb Johannes Schlüter:

On Fr, 2018-01-26 at 12:43 +0100, Hajo Locke wrote:

Hello List,

i hope this is the right place to get helped. I have a promising
setup
for testing purposes, but unfortunately i ran quick into problems.

   I compiled a minimal libphp7.so (7.2.1)  using this line:
./configure --disable-all  --enable-static --prefix=/usr
--with-apxs2=/usr/bin/apxs2 --enable-maintainer-zts

The enable mantainer zts should not be needed. The apache module tries
to identify the configuration an enable thread-safety automatically if
needed. I'd suggest removng the option and checking configure output
and config.log and trying to see what it identifies ... however there's
not much love for mpm_worker on the PHP side :-)

If all you want is to prevent apache from complaining about
php_value/php_flag directives for handling them elsewhere I'd suggest
writing a simple apache module which simply registers those settings
and does nothing else. Seems way less problematic.
Yes, i thought about that a few das ago, but believed it is to hard for 
me. But you are right, it is enought to tell apache about the 
directives, there is no need to add some further funtionality.
Iam not a programmer, just sysadmin. Following your 
sapi/apache2handler/apache_config.c i was able to put php_value etc. 
into this example-module and did a first run.
To my surprise this was successful. Configtest was ok, and on php-fpm 
side your htscanner still worked.
It seems this is a very promising way and i will invest more time in it 
to get this stable.

Thank you all.


Can be done mostly by copy and paste from that site:
http://httpd.apache.org/docs/2.4/developer/modguide.html#configuration

johannes


Thanks,
Hajo


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

RE: [PHP-DEV] threadsafe php crashes too easily

[Anatol Belski]

Hi,

> -Original Message-
> From: Hajo Locke [mailto:hajo.lo...@gmx.de]
> Sent: Friday, January 26, 2018 12:43 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] threadsafe php crashes too easily
> 
> Hello List,
> 
> i hope this is the right place to get helped. I have a promising setup for 
> testing
> purposes, but unfortunately i ran quick into problems.
> 
>   I compiled a minimal libphp7.so (7.2.1)  using this line:
> ./configure --disable-all  --enable-static --prefix=/usr
> --with-apxs2=/usr/bin/apxs2 --enable-maintainer-zts
> 
> I enabled threadsafety to use this libphp7.so in apache 2.4 with a threaded 
> mpm
> like worker or event. the plan is to just load it with LoadModule in apache 
> but
> not to use it.
> the real php-processing is done by a fastcgi-setup in apache using php-fpm 
> (not
> needed to reproduce error). the idea is to support php_value/php_flag etc. in
> .htaccess files for my users even if they use a fastcgi-setup. all i need is
> htscanner extension for php-cgi and just a loaded libphpx.so to register these
> directives in apache. may be this is a dump idea, but i have thousands of 
> users
> who use libphpx.so and a huge number of .htaccess with php_value/php_flag
> directives. currently i see no possibility to tell users to switch to 
> .user.ini
> 
> First steps are really successful and all worked well. Even benchmarking the
> system with massrequests did not show any error. php_value/php_flag in
> .htaccess showed expected behaviour when requesting a php-file using fastcgi.
> Unfortunately there is only a small change to see lots of segfaults in
> errorlog: Just enable a php_value directive in VHost-Config for this 
> particular
> VHost along with a php_value directive in .htaccess in docroot of this VHost. 
> It is
> not needed to request a php-file, just requesting a small static file is 
> enough. The
> smaller the requested file and higher requests per second the higher is count 
> of
> segfaults.
>
I just made a quick try with the way you've described - php_value once in 
httpd.conf and in .htaccess, but I see no crash. Perhaps you could file a 
ticket with a more detailed description and a backtrace you currently get.
 
> I knew that threadsafe-compiled php is a problematic thing and recommend
> mpm is prefork when not using a fastcgi-configuration, but iam surprised that 
> i
> see the crashes so easily. I used a minimal php and it seems problem occurs 
> just
> by reading and applying the values set by php_value for particular request.
> 
It depends on what you do. Some dependencies or even functions in the C runtime 
are not thread safe, one has to be aware what is used by an application.

Thanks

Anatol

Re: [PHP-DEV] threadsafe php crashes too easily

[Johannes Schlüter]

On Fr, 2018-01-26 at 12:43 +0100, Hajo Locke wrote:
> Hello List,
> 
> i hope this is the right place to get helped. I have a promising
> setup 
> for testing purposes, but unfortunately i ran quick into problems.
> 
>   I compiled a minimal libphp7.so (7.2.1)  using this line:
> ./configure --disable-all  --enable-static --prefix=/usr 
> --with-apxs2=/usr/bin/apxs2 --enable-maintainer-zts

The enable mantainer zts should not be needed. The apache module tries
to identify the configuration an enable thread-safety automatically if
needed. I'd suggest removng the option and checking configure output
and config.log and trying to see what it identifies ... however there's
not much love for mpm_worker on the PHP side :-)

If all you want is to prevent apache from complaining about
php_value/php_flag directives for handling them elsewhere I'd suggest
writing a simple apache module which simply registers those settings
and does nothing else. Seems way less problematic.

Can be done mostly by copy and paste from that site:
http://httpd.apache.org/docs/2.4/developer/modguide.html#configuration

johannes

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

Re: [PHP-DEV] threadsafe php crashes too easily

[Rowan Collins]

On 26 January 2018 at 11:43, Hajo Locke  wrote:

> the idea is to support php_value/php_flag etc. in .htaccess files for my
> users even if they use a fastcgi-setup
>


Just a thought, but if I understand you rightly, you just need to have
Apache completely ignore the php_value and php_flag lines, so would it work
to build a custom Apache extension which just registered for those
directives and did nothing?

I know it sounds complicated, but I was able to hack in support for the
UndefMacro keyword into an old version of mod_macro (result here:
https://github.com/IMSoP/mod_macro) and Apache ships with a very
user-friendly build tool called APXS [
https://httpd.apache.org/docs/2.4/programs/apxs.html]. It would probably
fairly simple to whip up a "mod_notphp" which does nothing but register
those two directives to empty callbacks.

Regards,
-- 
Rowan Collins
[IMSoP]

[PHP-DEV] threadsafe php crashes too easily

[Hajo Locke]

Hello List,

i hope this is the right place to get helped. I have a promising setup 
for testing purposes, but unfortunately i ran quick into problems.


 I compiled a minimal libphp7.so (7.2.1)  using this line:
./configure --disable-all  --enable-static --prefix=/usr 
--with-apxs2=/usr/bin/apxs2 --enable-maintainer-zts


I enabled threadsafety to use this libphp7.so in apache 2.4 with a 
threaded mpm like worker or event. the plan is to just load it with 
LoadModule in apache but not to use it.
the real php-processing is done by a fastcgi-setup in apache using 
php-fpm (not needed to reproduce error). the idea is to support 
php_value/php_flag etc. in .htaccess files for my users even if they use 
a fastcgi-setup. all i need is htscanner extension for php-cgi and just 
a loaded libphpx.so to register these directives in apache. may be this 
is a dump idea, but i have thousands of users who use libphpx.so and a 
huge number of .htaccess with php_value/php_flag directives. currently i 
see no possibility to tell users to switch to .user.ini


First steps are really successful and all worked well. Even benchmarking 
the system with massrequests did not show any error. php_value/php_flag 
in .htaccess showed expected behaviour when requesting a php-file using 
fastcgi.
Unfortunately there is only a small change to see lots of segfaults in 
errorlog: Just enable a php_value directive in VHost-Config for this 
particular VHost along with a php_value directive in .htaccess in 
docroot of this VHost. It is not needed to request a php-file, just 
requesting a small static file is enough. The smaller the requested file 
and higher requests per second the higher is count of segfaults.


I knew that threadsafe-compiled php is a problematic thing and recommend 
mpm is prefork when not using a fastcgi-configuration, but iam surprised 
that i see the crashes so easily. I used a minimal php and it seems 
problem occurs just by reading and applying the values set by php_value 
for particular request.


Do i have a chance to get this setup safe?

Thanks a lot,
Hajo

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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Rowan Collins]

On 26 January 2018 at 01:06, Michael Morris  wrote:

>
> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
> >
> > Our iterators cannot always be reliably rewound, such as
> > when using generators. Checking that the generator returns only
> > strings would consume all the input and would therefore be useless.
>
>
> True - I hadn't thought of those. But as of PHP 7 generators can type
> declare their return value.  So, given `$a instanceof iterable`, if
> $a is a reference to a generator, then the engine could check the return
> type declaration and only give true on a match without attempting to use
> the generator.
>
> We can follow this pattern farther - The return of an
> ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
> instanceof rather than actually pulling data from these methods.
>
> We are having the return rely on the promise of the code, but in each case
> TypeError would be raised anyway if it breaks it's promise to instanceof so
> errors aren't being avoided.
>


The more angles we approach this, the more it looks like generics, or at
least the same basis. For instance, what you're describing here is that
Iterator would act like an extra interface that restricted the
return type of current() to string. With full userland generics, that would
actually be declarable like this:

interface Iterator extends Iterator {
public function current(): T;
public function next(): T;
}

Which would basically be a template so that Iterator created an
appropriately constrained interface, which you can actually create already:

interface Iterator__string extends Iterator {
public function current(): string;
public function next(): string;
}

(You could actually use an auto-loader hack to do a lot of generics this
way.)

The main differences I can see between this and your suggestion are:

- If it's an actual interface, the class's definition would need to
explicitly list that it implements it. The wording you used implied that it
might be more implicit, and automatically label the class as an
"iterable" if the signatures matched.
- The iterable syntax would be able to cover arrays as well as
Iterators. We might decide that just as "iterable" stands for "Iterator or
array", "iterable" stands for "Iterator or string[]".
However, I think having "string[]" was previously rejected because of the
cost of checking every element of the array, particular when the type is
something slower to check, like "callable[]".

I think this fits with where Derick was going earlier: we could have
pseudo-generic interfaces like Iterator internally without a full
generics implementation. As long as the syntax and semantics were
compatible, these could then be a stepping-stone to full generics being
added later.

Regards,
-- 
Rowan Collins
[IMSoP]