Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 4:21 AM, Johannes Schlüter johan...@schlueters.de wrote: The approach I have in mind is going back to a consensus model by default, allowing truly everybody to participate and giving the opportunity to call for a vote if consensus can't be reached. It never worked in the last decade+, what makes you think it will work all of a sudden? All I see is some being afraid to loose control while all RFCs show that it is by far not the case. The active core devs did not loose control and we reached many consensuses. We have a couple of issues but the roots of them are very clear. All is all there is no reason to go back in a very bad time for php. Given our social diversity I however think that this hardly works out as there always will be somebody calling for a vote ... obvious consequence would be a quorum for calling for a vote .. wich ends up in even more bureaucracy hell. There is no bureaucracy hell but an end to endless discussions, pressures, and other nonconstructive behaviors. The recent RFC events about starting, ending, counting are unlucky but easily fixable. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Little switch improvement: get the used variable
Hello together,
i often write switches, where i throw an Exception when something unknown
come in, rather than using a default value.
switch($myVar){
case 1:
doSomethingElse();
break;
case 2:
doSomething();
break;
//...
default:
throw new Exception('Undefined input: ' . $myVar);
break;
}
I would like to write something like this:
switch($myVar){
//...
default:
throw new Exception('Undefined input: ' .
get_the_used_switch_variable());
break;
}
The `get_the_used_switch_variable()` is just a placeholder, name can be
changed to something natural...maybe a constant.
It's really usefull, when dealing with nested objects like when you work
with Doctrine.
Best regards
Martin
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On 2014-09-23 06:00, Sanford Whiteman wrote: What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. Sounds OK to me now that I've noticed this: https://bugs.php.net/bug.php?id=68081 Pretty sure that's a sane report, and it's enough to make me say checkdnsrr() doesn't work now at all. Given that this function is over 16 years old [1] and guessing that it was used as a simple kind of email domain verification, I think checkdnsrr() works as expected [2], [3]. [1] http://marc.info/?l=php-internalsm=90222489331812w=2 [2] http://tools.ietf.org/html/rfc2821#section-5 [3] http://tools.ietf.org/html/rfc5321#section-5.1 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
Hi Martin,
The `get_the_used_switch_variable()` is just a placeholder, name can be
changed to something natural...maybe a constant.
I feel this has diminished utility once you consider that the switch
variable is actually an expression and could well include multiple
$variables. Plus there's also the pattern switch(true) { } where the
interesting variables appear in case statements. Hard for me to see
the justification, but maybe I'm missing it. My $0.02...
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Tue, Sep 23, 2014 at 12:24 AM, Michael Wallner m...@php.net wrote: On 2014-09-23 06:00, Sanford Whiteman wrote: What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. Sounds OK to me now that I've noticed this: https://bugs.php.net/bug.php?id=68081 Pretty sure that's a sane report, and it's enough to make me say checkdnsrr() doesn't work now at all. Given that this function is over 16 years old [1] and guessing that it was used as a simple kind of email domain verification, I think checkdnsrr() works as expected [2], [3]. [1] http://marc.info/?l=php-internalsm=90222489331812w=2 [2] http://tools.ietf.org/html/rfc2821#section-5 [3] http://tools.ietf.org/html/rfc5321#section-5.1 -- Regards, Mike Except that it doesn't work as expected because most devs (including myself) aren't readily familiar with posts from 1998. And even if that were its purpose back then, that really has no relevance today, as the purpose and identity of PHP itself has evolved drastically since then. If that really is a concern, though, then I would propose getting rid of checkdnsrr() altogether (or making it an alias of checkmxrr()) and creating a new general-purpose DNS lookup function that returns a boolean. Of course, I really don't think that's necessary since this stuff from 16 years ago doesn't have any meaningful bearing on how it's being used today by modern PHP developers. --Kris
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On 2014-09-23 09:30, Kris Craig wrote: On Tue, Sep 23, 2014 at 12:24 AM, Michael Wallner m...@php.net mailto:m...@php.net wrote: On 2014-09-23 06:00, Sanford Whiteman wrote: What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. Sounds OK to me now that I've noticed this: https://bugs.php.net/bug.php?id=68081 Pretty sure that's a sane report, and it's enough to make me say checkdnsrr() doesn't work now at all. Given that this function is over 16 years old [1] and guessing that it was used as a simple kind of email domain verification, I think checkdnsrr() works as expected [2], [3]. [1] http://marc.info/?l=php-internalsm=90222489331812w=2 [2] http://tools.ietf.org/html/rfc2821#section-5 [3] http://tools.ietf.org/html/rfc5321#section-5.1 -- Regards, Mike Except that it doesn't work as expected because most devs (including myself) aren't readily familiar with posts from 1998. And even if that were its purpose back then, that really has no relevance today, as the purpose and identity of PHP itself has evolved drastically since then. If that really is a concern, though, then I would propose getting rid of checkdnsrr() altogether (or making it an alias of checkmxrr()) and creating a new general-purpose DNS lookup function that returns a boolean. Of course, I really don't think that's necessary since this stuff from 16 years ago doesn't have any meaningful bearing on how it's being used today by modern PHP developers. Phew, modern or rather unaware or uneager to research? Anyway, I'm done with this topic; I don't see any reason for action, except maybe, improving related documentation. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
I don't think you tracked the behavior in the bug report.
If checkdnsrr() is doing an MX query -- not including implicit MX,
only explicit MX -- it must fail when there is no MX record. It can't
return `true` when there is a CNAME (and no MX record for the
canonical hostname, only an A) but `false` when there is an A (and no
MX record). That isn't an MX query, nor is it the way smtp-senders
operate, now or 16 years ago.
To quote the bug report, if somehost.example.com is a CNAME for
example.com, and example.com has an A record but no MX,
checkdnsrr('somehost.example.com') must not return different results
than checkdnsrr('example.com'). Either the function is trying to be
smart and emulate an smtp-sender (bad idea) and succeeds on both, or
it stays dumb and fails on both.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Tue, Sep 23, 2014 at 12:38 AM, Michael Wallner m...@php.net wrote: On 2014-09-23 09:30, Kris Craig wrote: On Tue, Sep 23, 2014 at 12:24 AM, Michael Wallner m...@php.net mailto:m...@php.net wrote: On 2014-09-23 06:00, Sanford Whiteman wrote: What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. Sounds OK to me now that I've noticed this: https://bugs.php.net/bug.php?id=68081 Pretty sure that's a sane report, and it's enough to make me say checkdnsrr() doesn't work now at all. Given that this function is over 16 years old [1] and guessing that it was used as a simple kind of email domain verification, I think checkdnsrr() works as expected [2], [3]. [1] http://marc.info/?l=php-internalsm=90222489331812w=2 [2] http://tools.ietf.org/html/rfc2821#section-5 [3] http://tools.ietf.org/html/rfc5321#section-5.1 -- Regards, Mike Except that it doesn't work as expected because most devs (including myself) aren't readily familiar with posts from 1998. And even if that were its purpose back then, that really has no relevance today, as the purpose and identity of PHP itself has evolved drastically since then. If that really is a concern, though, then I would propose getting rid of checkdnsrr() altogether (or making it an alias of checkmxrr()) and creating a new general-purpose DNS lookup function that returns a boolean. Of course, I really don't think that's necessary since this stuff from 16 years ago doesn't have any meaningful bearing on how it's being used today by modern PHP developers. Phew, modern or rather unaware or uneager to research? Anyway, I'm done with this topic; I don't see any reason for action, except maybe, improving related documentation. -- Regards, Mike Wow that got personal really fast. I was just saying that, when most devs look-up a function on php.net, they don't also then search Google for any decades-old references that might yield some additional insight on the origin story of the function. I don't think that means they're not intellectually curious. --Kris
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Tue, Sep 23, 2014 at 9:41 AM, Sanford Whiteman
figureone...@gmail.com wrote:
I don't think you tracked the behavior in the bug report.
If checkdnsrr() is doing an MX query -- not including implicit MX,
only explicit MX -- it must fail when there is no MX record. It can't
return `true` when there is a CNAME (and no MX record for the
canonical hostname, only an A) but `false` when there is an A (and no
MX record). That isn't an MX query, nor is it the way smtp-senders
operate, now or 16 years ago.
To quote the bug report, if somehost.example.com is a CNAME for
example.com, and example.com has an A record but no MX,
checkdnsrr('somehost.example.com') must not return different results
than checkdnsrr('example.com'). Either the function is trying to be
smart and emulate an smtp-sender (bad idea) and succeeds on both, or
it stays dumb and fails on both.
if somehost.example.com has the MX, it should return true with
checkdnsrr('somehost.example.com'). If example has the MX set to
somehost.example.com or similar, it should return true as well. Or am
I missing your point?
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Invokation on __toString() for object used as array key
Hi all, until 5 minutes ago I thought it would be perfectly legal to use an object as an array key, given that its __toString() method is in place. Seems as if I was wrong. I know that array keys are not what is considered string context internally, at least not directly. Would it harm in any way to add that feature? Greetings Nico
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
if somehost.example.com has the MX, it should return true with
checkdnsrr('somehost.example.com'). If example has the MX set to
somehost.example.com or similar, it should return true as well. Or am
I missing your point?
You are missing it, as there are no MX records involved. I'm
demonstrating that the function gives incorrect results in the absence
of an MX record because there is a bug in CNAME handling (or a bug in
A handling, if you prefer).
somehost.example.com has no MX RR. It has a CNAME (per DNS rules, the
CNAME must thus be the only record for somehost.example.com). The
CNAME points to example.com.
example.com has no MX RR. It has an A pointing to 1.2.3.4.
checkdnsrr('somehost.example.com') should return false. It returns true.
checkdnsrr('example.com') should return false. It returns false.
You could try to revise the docs and say, Oh, it doesn't really mean
an MX lookup, it means an explicit MX *or* implicit MX, like how a
basic smtp-sender works. So that's why the CNAME -- A one returns
true. Except then 'example.com' should return true as well. It does
not: it returns false. Changing the docs does not fix the bug.
BTW, I've been reading SMTP RFCs since we were on good ol' 821, and
I'm plenty intellectually curious. I don't care if a function is
supposed to partially emulate an smtp-sender when verifying a domain,
or if it's supposed to run a dumb DNS MX query. It either does what
it's supposed to to do or it's broken.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On 09/22/2014 08:56 PM, Zeev Suraski wrote: The first bullet is the one this thread deals with so far. It clearly states that having an SVN account isn't enough - but that code contributions to PHP are mandatory. We should probably consider revising that to also account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. That's a horrible idea. From a very quick unscientific glance at https://github.com/php/php-src/graphs/contributors there's only ~50 people *ever* to have more than 20 commits in php-src. (Incidentally I'm at the very bottom with 22, should I be happy to just have made the cut if php-src commits are the only metric?) I'm not saying karma could be revoked after a few years, especially if there were cases where it was given back instantly on return, but this all sounds like a bureaucratic mess. Also, how do you value people reproducing bugs, checking the bugtracker, testing every build, etc.pp? There are a lot of tasks that are a lot more important in every day work than only writing internals code. I don't have a solution ready, but maybe I'm just too much in the middle ground - not a day to day contributor, but with an account nearly 11 years old and enough inactivity breaks of months to years I feel entitled enough to see both sides. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On 2014-09-23 10:11, Sanford Whiteman wrote:
if somehost.example.com has the MX, it should return true with
checkdnsrr('somehost.example.com'). If example has the MX set to
somehost.example.com or similar, it should return true as well. Or am
I missing your point?
You are missing it, as there are no MX records involved. I'm
demonstrating that the function gives incorrect results in the absence
of an MX record because there is a bug in CNAME handling (or a bug in
A handling, if you prefer).
somehost.example.com has no MX RR. It has a CNAME (per DNS rules, the
CNAME must thus be the only record for somehost.example.com). The
CNAME points to example.com.
example.com has no MX RR. It has an A pointing to 1.2.3.4.
checkdnsrr('somehost.example.com') should return false. It returns true.
checkdnsrr('example.com') should return false. It returns false.
You could try to revise the docs and say, Oh, it doesn't really mean
an MX lookup, it means an explicit MX *or* implicit MX, like how a
basic smtp-sender works. So that's why the CNAME -- A one returns
true. Except then 'example.com' should return true as well. It does
not: it returns false. Changing the docs does not fix the bug.
Ah okay, I think you're right. It shouldn't accept the CNAME.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 2014-09-23 10:04, Nicolai Scheer wrote: Hi all, until 5 minutes ago I thought it would be perfectly legal to use an object as an array key, given that its __toString() method is in place. Seems as if I was wrong. I know that array keys are not what is considered string context internally, at least not directly. Would it harm in any way to add that feature? Yes, it was removed intentionally (quite a long time ago), like using resources as array keys, to avoid hard-to-trace bugs for the user. At least that's the reasoning I can remember. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On 2014-09-23 10:47, Michael Wallner wrote:
On 2014-09-23 10:11, Sanford Whiteman wrote:
if somehost.example.com has the MX, it should return true with
checkdnsrr('somehost.example.com'). If example has the MX set to
somehost.example.com or similar, it should return true as well. Or am
I missing your point?
You are missing it, as there are no MX records involved. I'm
demonstrating that the function gives incorrect results in the absence
of an MX record because there is a bug in CNAME handling (or a bug in
A handling, if you prefer).
somehost.example.com has no MX RR. It has a CNAME (per DNS rules, the
CNAME must thus be the only record for somehost.example.com). The
CNAME points to example.com.
example.com has no MX RR. It has an A pointing to 1.2.3.4.
checkdnsrr('somehost.example.com') should return false. It returns true.
checkdnsrr('example.com') should return false. It returns false.
You could try to revise the docs and say, Oh, it doesn't really mean
an MX lookup, it means an explicit MX *or* implicit MX, like how a
basic smtp-sender works. So that's why the CNAME -- A one returns
true. Except then 'example.com' should return true as well. It does
not: it returns false. Changing the docs does not fix the bug.
Ah okay, I think you're right. It shouldn't accept the CNAME.
Looking at the source, though, neither the code nor the docs make any
assertions on the actual type of response they got. So it could still be
seen as works as expected, because it just checks if any answer is
received. If that functionality is useful could be debatable.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 23 September 2014 09:51, Michael Wallner m...@php.net wrote: Yes, it was removed intentionally (quite a long time ago), like using resources as array keys, to avoid hard-to-trace bugs for the user. At least that's the reasoning I can remember. He doesn't want to add the object as a key, he wants to invoke __toString(). Is there really any harm in adding a IS_OBJECT case to zend_whatever_add_array_element, and checking if it has a __toString? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Hi person hiding behind a project, Backwards compatibility is one hurdle, but if you wipe all your serialised data then begin to re-serialise using the new approach then you're fine. As for what to use msgpack or igbinary, well there's already good support for igbinary in PHP thanks to Pierre and others. You should benchmark igbinary vs msgpack and come back with your findings if we're to evaluate alternative serialization libraries. Many thanks, Paul On Tue, Sep 23, 2014 at 12:23 AM, Park Framework park.framew...@gmail.com wrote: PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 23 Sep 2014, at 10:15, Leigh lei...@gmail.com wrote: On 23 September 2014 09:51, Michael Wallner m...@php.net wrote: Yes, it was removed intentionally (quite a long time ago), like using resources as array keys, to avoid hard-to-trace bugs for the user. At least that's the reasoning I can remember. He doesn't want to add the object as a key, he wants to invoke __toString(). Is there really any harm in adding a IS_OBJECT case to zend_whatever_add_array_element, and checking if it has a __toString? It'd be great if, for the UString class krakjoe is working on, it could implicitly convert. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Tue, Sep 23, 2014 at 12:29 PM, Andrea Faulds a...@ajf.me wrote:
On 23 Sep 2014, at 10:15, Leigh lei...@gmail.com wrote:
On 23 September 2014 09:51, Michael Wallner m...@php.net wrote:
Yes, it was removed intentionally (quite a long time ago), like using
resources as array keys, to avoid hard-to-trace bugs for the user. At
least that's the reasoning I can remember.
He doesn't want to add the object as a key, he wants to invoke __toString().
Is there really any harm in adding a IS_OBJECT case to
zend_whatever_add_array_element, and checking if it has a __toString?
It does work if you do an explicit cast to string:
class Foo {
public function __toString()
{
return 'Bar';
}
}
$array = array();
$object = new Foo();
$array[(string) $object] = 'this works';
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 2014-09-23 11:15, Leigh wrote: On 23 September 2014 09:51, Michael Wallner m...@php.net wrote: Yes, it was removed intentionally (quite a long time ago), like using resources as array keys, to avoid hard-to-trace bugs for the user. At least that's the reasoning I can remember. He doesn't want to add the object as a key, he wants to invoke __toString(). Did I write that? Is there really any harm in adding a IS_OBJECT case to zend_whatever_add_array_element, and checking if it has a __toString? As already mentioned that behavior was intentionally removed. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 23 September 2014 10:35, Michael Wallner m...@php.net wrote: On 2014-09-23 11:15, Leigh wrote: He doesn't want to add the object as a key, he wants to invoke __toString(). Did I write that? No, you didn't, sorry. I just didn't see how an object with an explicit method to convert it to a string compared to using a resource straight up as a key. If you were implying the resource would be cast to int, then I get the comparison. Does it really make bugs that hard to find? You'd expect the user to know when they're using this behaviour when they write the code... well, I would. I suppose explicit casting removes any ambiguity, we use $a[(int)$resource] all the time for arrays of sockets and that's served us fine over the years. Hmm, thinking about it $a[(string)$object] is a lot clearer than having some magic sort it out. You're right, I'll retreat now :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 2014-09-23 11:45, Leigh wrote: On 23 September 2014 10:35, Michael Wallner m...@php.net wrote: On 2014-09-23 11:15, Leigh wrote: He doesn't want to add the object as a key, he wants to invoke __toString(). Did I write that? No, you didn't, sorry. I just didn't see how an object with an explicit method to convert it to a string compared to using a resource straight up as a key. If you were implying the resource would be cast to int, then I get the comparison. Does it really make bugs that hard to find? You'd expect the user to know when they're using this behaviour when they write the code... well, I would. I suppose explicit casting removes any ambiguity, we use $a[(int)$resource] all the time for arrays of sockets and that's served us fine over the years. Hmm, thinking about it $a[(string)$object] is a lot clearer than having some magic sort it out. You're right, I'll retreat now :) I'm a victim of $array[(int) $resource] myself. I just tried to explain that the behavior is intentional and not an oversight. That doesn't mean that is set in stone for all times. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi, I do believe that the UString class would benefit from such a change. Why would it be confusing to implement this? Regards, *Florian Margaine* Le 23 sept. 2014 12:42, Michael Wallner m...@php.net a écrit : On 2014-09-23 11:45, Leigh wrote: On 23 September 2014 10:35, Michael Wallner m...@php.net wrote: On 2014-09-23 11:15, Leigh wrote: He doesn't want to add the object as a key, he wants to invoke __toString(). Did I write that? No, you didn't, sorry. I just didn't see how an object with an explicit method to convert it to a string compared to using a resource straight up as a key. If you were implying the resource would be cast to int, then I get the comparison. Does it really make bugs that hard to find? You'd expect the user to know when they're using this behaviour when they write the code... well, I would. I suppose explicit casting removes any ambiguity, we use $a[(int)$resource] all the time for arrays of sockets and that's served us fine over the years. Hmm, thinking about it $a[(string)$object] is a lot clearer than having some magic sort it out. You're right, I'll retreat now :) I'm a victim of $array[(int) $resource] myself. I just tried to explain that the behavior is intentional and not an oversight. That doesn't mean that is set in stone for all times. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch m...@anderiasch.de wrote: On 09/22/2014 08:56 PM, Zeev Suraski wrote: The first bullet is the one this thread deals with so far. It clearly states that having an SVN account isn't enough - but that code contributions to PHP are mandatory. We should probably consider revising that to also account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. That's a horrible idea. From a very quick unscientific glance at https://github.com/php/php-src/graphs/contributors there's only ~50 people *ever* to have more than 20 commits in php-src. (Incidentally I'm at the very bottom with 22, should I be happy to just have made the cut if php-src commits are the only metric?) I'm not saying karma could be revoked after a few years, especially if there were cases where it was given back instantly on return, but this all sounds like a bureaucratic mess. Also, how do you value people reproducing bugs, checking the bugtracker, testing every build, etc.pp? There are a lot of tasks that are a lot more important in every day work than only writing internals code. I don't have a solution ready, but maybe I'm just too much in the middle ground - not a day to day contributor, but with an account nearly 11 years old and enough inactivity breaks of months to years I feel entitled enough to see both sides. also the method is by far buggy, for me at least :) I have way more than 133 commits in php history, maybe got lost somehow in git migration, no idea :) https://www.openhub.net/p/php/contributors?query=sort=commits shows more but also incomplete, for what php-src contains. The funny part is when we look at the recent, or 1-5 years activity, if we begin to apply such insane filters to allow votes, some may not even vote anymore. In short, let trash this horrible idea. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Performance testing, Msgpack VS Igbinary igbinary: -20% slower, data size ~5% Advantage Msgpack, he works fast, and this format understood by many technologies - Java, Python, Lua in Redis. 2014-09-23 12:20 GMT+03:00 Paul Dragoonis dragoo...@gmail.com: Hi person hiding behind a project, Backwards compatibility is one hurdle, but if you wipe all your serialised data then begin to re-serialise using the new approach then you're fine. As for what to use msgpack or igbinary, well there's already good support for igbinary in PHP thanks to Pierre and others. You should benchmark igbinary vs msgpack and come back with your findings if we're to evaluate alternative serialization libraries. Many thanks, Paul On Tue, Sep 23, 2014 at 12:23 AM, Park Framework park.framew...@gmail.com wrote: PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Write an extension for it then, also share your benchmarks :) On Tue, Sep 23, 2014 at 12:17 PM, Park Framework park.framew...@gmail.com wrote: Performance testing, Msgpack VS Igbinary igbinary: -20% slower, data size ~5% Advantage Msgpack, he works fast, and this format understood by many technologies - Java, Python, Lua in Redis. 2014-09-23 12:20 GMT+03:00 Paul Dragoonis dragoo...@gmail.com: Hi person hiding behind a project, Backwards compatibility is one hurdle, but if you wipe all your serialised data then begin to re-serialise using the new approach then you're fine. As for what to use msgpack or igbinary, well there's already good support for igbinary in PHP thanks to Pierre and others. You should benchmark igbinary vs msgpack and come back with your findings if we're to evaluate alternative serialization libraries. Many thanks, Paul On Tue, Sep 23, 2014 at 12:23 AM, Park Framework park.framew...@gmail.com wrote: PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
On 23 September 2014 12:22, Paul Dragoonis dragoo...@gmail.com wrote: Write an extension for it then, also share your benchmarks :) Why go to all that trouble, 10 seconds on Google and we have: https://github.com/msgpack/msgpack-php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
http://pecl.php.net/package/msgpack On Tue, Sep 23, 2014 at 1:34 PM, Leigh lei...@gmail.com wrote: On 23 September 2014 12:22, Paul Dragoonis dragoo...@gmail.com wrote: Write an extension for it then, also share your benchmarks :) Why go to all that trouble, 10 seconds on Google and we have: https://github.com/msgpack/msgpack-php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch m...@anderiasch.de wrote: On 09/22/2014 08:56 PM, Zeev Suraski wrote: The first bullet is the one this thread deals with so far. It clearly states that having an SVN account isn't enough - but that code contributions to PHP are mandatory. We should probably consider revising that to also account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. That's a horrible idea. From a very quick unscientific glance at https://github.com/php/php-src/graphs/contributors there's only ~50 people *ever* to have more than 20 commits in php-src. (Incidentally I'm at the very bottom with 22, should I be happy to just have made the cut if php-src commits are the only metric?) from a quick look that list only contains the contributors with an existing (and matching) github account. there are around 170 accounts with 20 or more commits: https://gist.github.com/Tyrael/3bf0d24d33cf6b9e828b ofc. some of those accounts are technical ones like the one with the empty name (was used for changelog entries from a quick look), and there are also some commits which were done by the same person but using different email/author name. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
On Tue, Sep 23, 2014 at 7:39 AM, Daniel Lowrey rdlow...@gmail.com wrote: Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a 5.6.1RC2 (tag is tomorrow) 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on odd weeks whereas 5.5 is on even weeks. Waiting for Ferenc's advice anyway. Julien.P I have no issues with reverting at this point as that's the best route to get stable releases back on track. I thought I had fixed some really old bugs with those commits but the medicine turned out to be worse than the disease. My apologies again for letting those problems sneak into releases :/ I've got the necessary fixes lined up at this point, I just need to know how you guys would prefer to proceed on this. I can commit the relevant changes to 5.4, 5.5 and 5.6 and double-check with RMs to ensure they make it into this next set of releases or we can revert the previous commits and forget about the bug fixes altogether. Just let me know which you prefer. Thanks. hi, I would prefer reverting the regression from 5.6.1, and I would be fine having the proper fix later on, but I think it would be nice if we could keep that off from the stable branches until we can validate (feedback from the Horde guys would be nice but it would really help a ton if we could have tests for both the original problem this was intended to fix and for the regression introduced while doing so) that the patch is now proper (maybe keeping it in a pull request in the meanwhile). What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 4:13 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch m...@anderiasch.de wrote: On 09/22/2014 08:56 PM, Zeev Suraski wrote: The first bullet is the one this thread deals with so far. It clearly states that having an SVN account isn't enough - but that code contributions to PHP are mandatory. We should probably consider revising that to also account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. That's a horrible idea. From a very quick unscientific glance at https://github.com/php/php-src/graphs/contributors there's only ~50 people *ever* to have more than 20 commits in php-src. (Incidentally I'm at the very bottom with 22, should I be happy to just have made the cut if php-src commits are the only metric?) from a quick look that list only contains the contributors with an existing (and matching) github account. there are around 170 accounts with 20 or more commits: https://gist.github.com/Tyrael/3bf0d24d33cf6b9e828b ofc. some of those accounts are technical ones like the one with the empty name (was used for changelog entries from a quick look), and there are also some commits which were done by the same person but using different email/author name. Even that list is not complete - it shows me with only 1 commit while I've got 2 pull requests merged. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
I clearly didn't google, it would be interesting to see comparisons of high speed PHP serialization libraries. I for one would be happy, in PHP 7, to break BC serialization syntax in favour of putting in a much faster serializer by default. Similar scenario to putting in Zend OpCache by default instead of APC. Pierre, do you see merit on including insert best overall serializer lib here by default in PHP7 ? On Tue, Sep 23, 2014 at 12:57 PM, Pierre Joye pierre@gmail.com wrote: http://pecl.php.net/package/msgpack On Tue, Sep 23, 2014 at 1:34 PM, Leigh lei...@gmail.com wrote: On 23 September 2014 12:22, Paul Dragoonis dragoo...@gmail.com wrote: Write an extension for it then, also share your benchmarks :) Why go to all that trouble, 10 seconds on Google and we have: https://github.com/msgpack/msgpack-php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
That's a horrible idea. From a very quick unscientific glance at https://github.com/php/php-src/graphs/contributors there's only ~50 people *ever* to have more than 20 commits in php-src. I believe this may be partially due to the fact that github will only show contributors to the default branch (master in our case). There are some other reasons why commits may not be attributed; see https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile Obviously this was just a very unscientific scan, but worth noting.
Re: [PHP-DEV] Improve PHP 7 serialization
Park Framework wrote (on 23/09/2014): PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better? Apart from the BC implications, using a binary serialization by default might cause issues with anyone who is storing or passing the serialized data somewhere which is not binary-safe. Admittedly, any object with private properties generates a serialized form with null bytes, but many values will consist entirely of ASCII characters, and some code may rely on this being the case. The format is also widely known, and has been implemented in other languages for compatibility (although it is **not** suitable for untrusted data exchange, as Anthony Ferrara tweeted a few months ago: https://twitter.com/ircmaxell/status/452182852562862080) We already have pluggable serializers for sessions (needed because the serialization happens implicitly in the session handling code), and can add as many functions for types of serialization as seem sensible, so I'm not sure what the benefit of changing serialize()/unserialize() themselves is. Changing the default *session* serialization might be worth considering, though, along with bundling something like igbinary or msgpack. Oh, and a non-batshit version of session_decode() for manually invoking session (un)serialization handlers :P -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 3:27 PM, Andrey Andreev n...@devilix.net wrote: On Tue, Sep 23, 2014 at 4:13 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch m...@anderiasch.de wrote: On 09/22/2014 08:56 PM, Zeev Suraski wrote: The first bullet is the one this thread deals with so far. It clearly states that having an SVN account isn't enough - but that code contributions to PHP are mandatory. We should probably consider revising that to also account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. That's a horrible idea. From a very quick unscientific glance at https://github.com/php/php-src/graphs/contributors there's only ~50 people *ever* to have more than 20 commits in php-src. (Incidentally I'm at the very bottom with 22, should I be happy to just have made the cut if php-src commits are the only metric?) from a quick look that list only contains the contributors with an existing (and matching) github account. there are around 170 accounts with 20 or more commits: https://gist.github.com/Tyrael/3bf0d24d33cf6b9e828b ofc. some of those accounts are technical ones like the one with the empty name (was used for changelog entries from a quick look), and there are also some commits which were done by the same person but using different email/author name. Even that list is not complete - it shows me with only 1 commit while I've got 2 pull requests merged. one of your pr's did not keep the author info, it seems as it was squashed into a single commit: http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff so it isn't a problem with the list, but how your PR was merged. ofc. probably there are other similar cases, so the potential number of people with more than 20 commits could be different, but this the info we have easy access to, and I don't think that it would change the numbers significantly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
On Tue, Sep 23, 2014 at 3:24 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Sep 23, 2014 at 7:39 AM, Daniel Lowrey rdlow...@gmail.com wrote: Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a 5.6.1RC2 (tag is tomorrow) 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on odd weeks whereas 5.5 is on even weeks. Waiting for Ferenc's advice anyway. Julien.P I have no issues with reverting at this point as that's the best route to get stable releases back on track. I thought I had fixed some really old bugs with those commits but the medicine turned out to be worse than the disease. My apologies again for letting those problems sneak into releases :/ I've got the necessary fixes lined up at this point, I just need to know how you guys would prefer to proceed on this. I can commit the relevant changes to 5.4, 5.5 and 5.6 and double-check with RMs to ensure they make it into this next set of releases or we can revert the previous commits and forget about the bug fixes altogether. Just let me know which you prefer. Thanks. hi, I would prefer reverting the regression from 5.6.1, and I would be fine having the proper fix later on, but I think it would be nice if we could keep that off from the stable branches until we can validate (feedback from the Horde guys would be nice but it would really help a ton if we could have tests for both the original problem this was intended to fix and for the regression introduced while doing so) that the patch is now proper (maybe keeping it in a pull request in the meanwhile). What do you think? For me its all right and safe. Next week we'll have 5.5.18RC1, which could contain the fix if it's been validated and want to go for an RC stage. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
one of your pr's did not keep the author info, it seems as it was squashed into a single commit: http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff so it isn't a problem with the list, but how your PR was merged. ofc. probably there are other similar cases, so the potential number of people with more than 20 commits could be different, but this the info we have easy access to, and I don't think that it would change the numbers significantly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu I do not think it makes sense to take the number of commits as metric. People's commit behaviour is different. Some commit only once after everything is done and others commit regularly after each achieved small step towards the goal. I belong rather to the second group. Why should I be favoured over another person who has only one commit in his pull request? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 4:47 PM, Robert Stoll p...@tutteli.ch wrote: one of your pr's did not keep the author info, it seems as it was squashed into a single commit: http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff so it isn't a problem with the list, but how your PR was merged. ofc. probably there are other similar cases, so the potential number of people with more than 20 commits could be different, but this the info we have easy access to, and I don't think that it would change the numbers significantly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu I do not think it makes sense to take the number of commits as metric. People's commit behaviour is different. Some commit only once after everything is done and others commit regularly after each achieved small step towards the goal. I belong rather to the second group. Why should I be favoured over another person who has only one commit in his pull request? are you favored? I was just pointing out a factual error about a claim in an earlier message and how other factors can influence the number of commits counted attributed to a person. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Improve PHP 7 serialization
On Sep 23, 2014 3:31 PM, Paul Dragoonis dragoo...@gmail.com wrote: I clearly didn't google, it would be interesting to see comparisons of high speed PHP serialization libraries. I for one would be happy, in PHP 7, to break BC serialization syntax in favour of putting in a much faster serializer by default. Similar scenario to putting in Zend OpCache by default instead of APC. Pierre, do you see merit on including insert best overall serializer lib here by default in PHP7 ? Not really, not because it is not good but because there is always be a better one. We can't break format in every release.
AW: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
I do not think it makes sense to take the number of commits as metric. People's commit behaviour is different. Some commit only once after everything is done and others commit regularly after each achieved small step towards the goal. I belong rather to the second group. Why should I be favoured over another person who has only one commit in his pull request? are you favored? I was just pointing out a factual error about a claim in an earlier message and how other factors can influence the number of commits counted attributed to a person. Sorry, you obviously interpreted my message in a way I did not intend to bring it over. I did not intend to attack you or something. I merely wanted to point out that there are additional aspects which makes number of commits a rather fuzzy metric. If this metric were be used then people which commit more regularly would be favoured and with committing regularly I do not mean implement many features, fixing bugs etc. but just that they use the git command commit more often than others. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 23, 2014 at 5:35 PM, Robert Stoll p...@tutteli.ch wrote: I do not think it makes sense to take the number of commits as metric. People's commit behaviour is different. Some commit only once after everything is done and others commit regularly after each achieved small step towards the goal. I belong rather to the second group. Why should I be favoured over another person who has only one commit in his pull request? are you favored? I was just pointing out a factual error about a claim in an earlier message and how other factors can influence the number of commits counted attributed to a person. Sorry, you obviously interpreted my message in a way I did not intend to bring it over. I did not intend to attack you or something. I merely wanted to point out that there are additional aspects which makes number of commits a rather fuzzy metric. If this metric were be used then people which commit more regularly would be favoured and with committing regularly I do not mean implement many features, fixing bugs etc. but just that they use the git command commit more often than others. and I completely agree with that. replying to my email (which only corrected some numbers) seemed like you are assuming/projecting that it was my idea to bring those numbers to the discussion. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, Sep 22, 2014 at 10:19 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I didn’t close it because the time suited me most. I made an honest mistake and closed it 22 or so hours early because I forgot I’d opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after merging the patch. This was definitely not intentional. That's why we should not rush to merge changes on a vote when there are significant objections. There's nothing that mandated this change to be merged immediately after the voting closing, as far as I can see. Yes, we do not want to make the process endless, but it's better to wait just a bit and ensure everybody is satisfied or at least reasonably listened to. Begging people off-list to retract the votes and then close it earlier on a very marginal result definitely looks like gaming the system, even if the intent was not to do that. But the intent is only known to one person, and the actions can be seen by all, so I think it's better to take extra care here. We want the voting to be means of enhancing the consensus, not something that would leave people losing the confidence in the whole process. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php yeah, and when there is like 12 minutes between the last required vote casted and the vote being casted(almost a day earlier), it is easy to jump to conclusions. but putting that aside, what do we do now? Personally I agree that it is a valid concern that some people could have missed the voting period because of this: We already discussed recently that even a week is a bit short (anybody can have a week of vacation etc.) but that is the minimum mandated by the voting rfc, and seeing how close the vote was, I think it would be a good idea to extend the voting. What do you think? ps: I would prefer not reverting the change to save some work/history obfuscation in case if the result stays. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: VCS Account Request: fmargaine
VCS Account Approved: fmargaine approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: leigh
VCS Account Approved: leigh approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 23 Sep 2014, at 16:57, Ferenc Kovacs tyr...@gmail.com wrote: yeah, and when there is like 12 minutes between the last required vote casted and the vote being casted(almost a day earlier), it is easy to jump to conclusions. The vote closing soon after the last vote was not a coincidence, but it’s the other way round from what you might think. That vote was deliberately made by them just before it was going to close (they asked me when I was going to close it), because they didn’t want it to fail by one vote. Had I not got that vote I’d still have closed it when I did, and it would have failed. but putting that aside, what do we do now? Personally I agree that it is a valid concern that some people could have missed the voting period because of this: We already discussed recently that even a week is a bit short (anybody can have a week of vacation etc.) but that is the minimum mandated by the voting rfc, and seeing how close the vote was, I think it would be a good idea to extend the voting. What do you think? ps: I would prefer not reverting the change to save some work/history obfuscation in case if the result stays. If we’re re-opening things, let’s just hold the vote again, rather than extending the existing vote. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Not really, not because it is not good but because there is always be a better one. We can't break format in every release. If you do not update in PHP 7 serialization method, it will never be updated, the default serialization in PHP 7 will be slow. To maintain backward compatibility, can implement support method calls on primitive types, new algorithms for serialization to be called only in the new API. $var-serialize() $var-unserialize() What do you think about this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
On Tue, Sep 23, 2014 at 7:36 PM, Park Framework park.framew...@gmail.com wrote: Not really, not because it is not good but because there is always be a better one. We can't break format in every release. If you do not update in PHP 7 serialization method, it will never be updated, the default serialization in PHP 7 will be slow. To maintain backward compatibility, can implement support method calls on primitive types, new algorithms for serialization to be called only in the new API. $var-serialize() $var-unserialize() What do you think about this? Not changing the serialize() format doesn't mean that other formats can't be introduced via extensions. Though, I too would like to have more of them available by default. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Remove alternative PHP tags
On Wed, Sep 10, 2014 at 12:08 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've created a small RFC proposing the removal of the alternative PHP opening/closing tags: https://wiki.php.net/rfc/remove_alternative_php_tags It removes % and script language=php and the other variations of asp and script tags. As a heads up, I'll start voting on this RFC tomorrow. Since the original submission the following changes have been made: * Addition of a script porting legacy tags to normal PHP tags. * Throwing a core error when trying to enable asp_tags. (Same as what we do for many other removed ini options.) Nikita
Re: [PHP-DEV] Improve PHP 7 serialization
On 23 September 2014 17:36, Park Framework park.framew...@gmail.com wrote: If you do not update in PHP 7 serialization method, it will never be updated, the default serialization in PHP 7 will be slow. To maintain backward compatibility, can implement support method calls on primitive types, new algorithms for serialization to be called only in the new API. $var-serialize() $var-unserialize() What do you think about this? To maintain backward compatibility we leave the behaviour of un/serialize() in tact. There are extensions for alternative serialisation methods and regardless of whether any of these becomes a bundled extension, the functionality should exist under a different set of function names. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
-Original Message- From: Robert Stoll [mailto:p...@tutteli.ch] Sent: Tuesday, September 23, 2014 5:48 PM To: 'Ferenc Kovacs'; 'Andrey Andreev' Cc: 'Florian Anderiasch'; 'Zeev Suraski'; 'Derick Rethans'; 'Andrea Faulds'; 'PHP internals' Subject: AW: [PHP-DEV] Is it fair that people with no karma can vote on RFCs? one of your pr's did not keep the author info, it seems as it was squashed into a single commit: http://git.php.net/?p=php- src.git;a=commit;h=ec2fff80e768dfb04aa393c06 a2b1a42a9e871ff so it isn't a problem with the list, but how your PR was merged. ofc. probably there are other similar cases, so the potential number of people with more than 20 commits could be different, but this the info we have easy access to, and I don't think that it would change the numbers significantly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu I do not think it makes sense to take the number of commits as metric. I'd welcome better suggestions if anybody has any. I think the complete lack of metrics and exceptionally low barrier to voting is a much bigger problem. Perhaps LoC? That said, 20 commits is an exceptionally low bar IMHO to get a say for a project with a *HUGE* impact such as PHP. I think it might look high since people got used to the idea that they can vote even if they've never contributed anything to PHP at all. I suspect that if I asked people from the Linux Kernel community what they think about the idea that someone who contributed 20 commits to the kernel would have the same say as Linus Torvalds, they'd think I had a bit too much to drink. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
Hi Mike, So it could still be seen as works as expected, because it just checks if any answer is received. If that functionality is useful could be debatable. That's not expected. Chasing (dereferencing) CNAMEs is one of the understood burdens of any DNS app; you can't treat the CNAME itself as a positive response. Luckily standard apps don't rely on DNS-to-boolean conversion like this or else the 'Net wouldn't work. I'm glad you see I wasn't blowing smoke here. -- S. P.S. chekdnsrr() does the same thing for CNAMEs w/other RRtypes as well, by the way. It'll confirm that www.php.net has an SRV record. I mean, geez... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sep 23, 2014 8:17 PM, Zeev Suraski z...@zend.com wrote: I'd welcome better suggestions if anybody has any. I think the complete lack of metrics and exceptionally low barrier to voting is a much bigger problem. Please point me at a vote where the author is not part of what you defined (and the rfc): - php karma (doc) - lead of leading projects Now to create classes along developers or regular contributors is the worst idea we can have. It says that writing docs is less valuable than a PoC. Wrong in so many ways. Perhaps LoC? Oh gosh... That said, 20 commits is an exceptionally low bar IMHO to get a say for a project with a *HUGE* impact such as PHP. And what's about zero commit in 5+ years? This discussion has the bad taste of creating a kind of elite in php.net.
Re: [PHP-DEV] Improve PHP 7 serialization
Hi! I clearly didn't google, it would be interesting to see comparisons of high speed PHP serialization libraries. I for one would be happy, in PHP 7, to break BC serialization syntax in favour of putting in a much faster serializer by default. Similar scenario to putting in Zend OpCache by default instead of APC. Why break anything? If you need faster serializer, it's quite easy to get one, including msgpack. If it is really an issue that is important for people, we could include the package into core. But I don't see breaking BC in serialize/unserialize as a big win here. If it's really a bottleneck, a userspace package abstracting the specific serializer function could be easily created - and most clients like sessions already allow to switch serializers by configs. So BC break does not seem to be warranted here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
On 23 September 2014 12:17:35 GMT+01:00, Park Framework park.framew...@gmail.com wrote: Performance testing, Msgpack VS Igbinary igbinary: -20% slower, data size ~5% As with any benchmark, the details of the test are rather important. Firstly, some data structures may be better handled than others, or be targeted for extra optimization, making some scenarios favour one method or the other. Some care needs to be taken in simulating one or more realistic use-cases. Secondly, speed to serialize and speed to unserialize are separate measures: igbinary openly admits that it is best used for things like caching, where reading occurs more often than writing, as it is often slower than text-based methods at write-time, but faster at read-time. Thirdly, the algorithms may have optional features which trade speed for space, or affect the above two points. For instance, igbinary's string interning, or the choice of structure used for objects in a PHP msgpack implementation. All that taken into account, it's unlikely that any one format is better in all situations, and in some cases the existing text-based format may even have measurable advantages. Which points again to the idea of making more algorithms available as bundled extensions, and as session serialization methods, but not changing the meaning of existing functions. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Why break anything? If you need faster serializer, it's quite easy to get one, including msgpack. If it is really an issue that is important for people, we could include the package into core. But I don't see breaking BC in serialize/unserialize as a big win here. If it's really a bottleneck, a userspace package abstracting the specific serializer function could be easily created - and most clients like sessions already allow to switch serializers by configs. So BC break does not seem to be warranted here. Perhaps a compromise would be to choose the quickest method of serialization, add it to PHP core. In php.ini add the directive serialization.method = msgpack / Igbinary / -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Hi! Perhaps a compromise would be to choose the quickest method of serialization, add it to PHP core. In php.ini add the directive serialization.method = msgpack / Igbinary / We could, but what if you need to read/write data specifically from current PHP serializer? You'd have to mess then with runtime directives, it doesn't look like a good design. That's like having one db_query() function for all databases and have a config parameter that switches the global database type. I think the other option is better - to have extensions for all underlying functions and abstraction layer (PDO or userspace) that provides unified API if needed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi! I do believe that the UString class would benefit from such a change. Why would it be confusing to implement this? For some objects, it may lead to rather strange results - i.e., Exception has __toString() but probably not very useful one for use as an array key. So may some other __toString methods. But in general, if we streamline the conversion rules and set expectations, I don't see why PHP engine can not check for object's convertor to string and even to int if string one is not there. Yes, that would hide some errors but also will enable some capabilities (like much smoother work with objects that may simulate numbers, akin to GMP). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
Hi! Good evening again, Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow Thoughts appreciated, as is help with the patch, though I can probably manage on my own. It would be nice to describe why this change is good. So far the motivation is it is unintuitive which is a fancy way of saying I don't like it. Could you list which use cases this functionality improves, which real-life bugs it could fix, etc.? If this is necessary for your BigInt RFC which would not work without it for some reason (I have no idea if it is the case, but if it is) then please state so explicitly and describe why. That may also help to find alternatives in case somebody else sees any other solution that you may have missed. If there are some other arguments for it, please add them to the RFC. Right now it looks kind of thin. I personally don't have any reason to assume what you are proposing is better that what we have now, and BC break is a cost that always must be offset by something that is worth more. Especially a BC break in a form of it worked before but now it fails - this can break code in so many hard to catch ways, where you didn't actually care at the least if the function truncates the arg (common situation in proxy/glue libraries, etc. - they'd be completely fine with garbage in - garbage out) but need special code to handle situations where the function fails to run altogether. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
Hi! Most? Python has it, java too, ruby and perl not. We can continue to list those having them or not, not sure that brings much to this discussion. Only Python 3 has it, and I'm not sure bringing up Python 3, given its known adoption issues, is the best example how we could plan PHP 7. In any case, python 3 seems to be rather an exception than the rule amongst scripting/dynamic languages, as it seems to me. That brings to this discussion an argument that if people that have no PHP baggage, no BC issues related to existing PHP code, etc. but working in roughly the same space as PHP under roughly the same paradigms chose to forego strict typing in that context - maybe it's not such a stupid idea. Maybe we can learn from their experience too. We've often borrowed from other languages, so consider it a case of negative borrowing :) Everyone I asked wants it, be at conferences, UGs, or devolopers of one of the top tools or framework out there. There was also http://www.php-vote.com/browse/latest showing in the top requests. This site has whopping 44 votes for type hints with scalar types and 52 for 100% unicode. It is rather hard for me to take it as a data point that it is requested for everybody. In any case, this endless discussion leads nowhere and we are not going to have anything done using such debates and arguing. OK, how do you propose to make anything done? Just ram through whatever gets through the vote at random moment of time, whatever the disagreements and issues are? Use some process which would allow us to find a better solution? Which process? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
I agree, you're right. My desire to override the existing algorithm serialize(), due to the need to change the method serialization, but does not change the source code (legacy code, ext PHP) 2014-09-24 3:03 GMT+03:00 Stas Malyshev smalys...@sugarcrm.com: Hi! Perhaps a compromise would be to choose the quickest method of serialization, add it to PHP core. In php.ini add the directive serialization.method = msgpack / Igbinary / We could, but what if you need to read/write data specifically from current PHP serializer? You'd have to mess then with runtime directives, it doesn't look like a good design. That's like having one db_query() function for all databases and have a config parameter that switches the global database type. I think the other option is better - to have extensions for all underlying functions and abstraction layer (PDO or userspace) that provides unified API if needed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
Hi! I'll implement optional (and not default) support of IDN in filter_var(). Does anyone known if it's better to use libIDN (LGPL) or ICU (custom license deviated from the X license) from a license point of view? ICU is definitely better since we already have a lot of code using ICU and AFAIK our current IDN functions (idn_to_*) use ICU. Which means it would be advantageous to keep it in the single library - whatever bugs there may be, at least the user will be dealing with one set of bugs instead of two :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Hi 2014-09-23 23:56 GMT+02:00 Park Framework park.framew...@gmail.com: In php.ini add the directive serialization.method = msgpack / Igbinary / There is an even better way to do this; add an additional parameter to serialize and unserialize to serialize as and unserialize as: $bin = serialize($data_struct, 'igbinary'); $data_struct = unserialize($bin, 'igbinary'); This keeps a clean BC solution without adding more clutter to the ini file for runtime things, you could say that adding something like 'serialize_default_mode = php;', but changing its default would create clutter code where the optional second parameter would be forced, so lets leave the ini out of this. So what I propose here is: 1) An internal API to register serializes,and making PHP's current serialize implemented as such 2) Add a second parameter to both serialize and unserialize that can be used choose a serializer 3) Optionally add a function like: get_serialize_handlers() (so we won't have to parse phpinfo()) which are the available serializers 4) Consider bundling either igbinary, msgpack or implement a new custom and more efficient one that allows us to be future oriented 5) No php.ini changes 6) Allow users to register serialize handlers using register_serialize_handler()/unregister_serialize_handler() 7) Optionally consider implementing this in SPL Okay, late night, back to sleep! -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
Hi! There is an even better way to do this; add an additional parameter to serialize and unserialize to serialize as and unserialize as: $bin = serialize($data_struct, 'igbinary'); $data_struct = unserialize($bin, 'igbinary'); This is cleaner, but if you can do this (code change), why you can't do just igbinary_serialize($data_struct)? 3) Optionally add a function like: get_serialize_handlers() (so we won't have to parse phpinfo()) which are the available serializers That actually makes a lot of sense, but serialize_get_handlers() might be a better name, to group them together. But right now I don't think we have such list, do we? We have php_session_register_serializer() and the list for sessions, but not for other contexts. 6) Allow users to register serialize handlers using register_serialize_handler()/unregister_serialize_handler() Do you think userspace serialize handlers would be popular? They would be by necessity pretty slow compared to C ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24/09/14 02:08, Stas Malyshev wrote: Hi! I do believe that the UString class would benefit from such a change. Why would it be confusing to implement this? For some objects, it may lead to rather strange results - i.e., Exception has __toString() but probably not very useful one for use as an array key. So may some other __toString methods. But in general, if we streamline the conversion rules and set expectations, I don't see why PHP engine can not check for object's convertor to string and even to int if string one is not there. Yes, that would hide some errors but also will enable some capabilities (like much smoother work with objects that may simulate numbers, akin to GMP). Well, then let's remove this restriction from resources, too. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
