@Larry
RFC is not updated with the solution for cloning yet. So far I did add
changes on which we have agreed on. Currently we have to candidates:
First one is to have copy on write (As Christoph pointed out, we had that
in PHP 4).
Second proposal is to introduce "transformer" keyword as a method
Sent: Sunday, September 11, 2016 11:44 AM
>To: Tony Marston
>Cc: Stanislav Malyshev ; internals@lists.php.net
>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
>
>On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston wrote:
>
>Sent: Saturday, September 10, 2016 7:47 PM
>>To:
Sent: Sunday, September 11, 2016 8:32 PM
>To: Tony Marston ; Stanislav Malyshev ; internals@lists.php.net
>Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
>
>
>On 09/11/2016 10:47 AM, Tony Marston wrote:
>> Sent: Saturday, September 10, 2016 7:47 PM
>>> To: Tony Mars
On Sep 12, 2016 2:36 PM, "Tony Marston" wrote:
>
> Sent: Sunday, September 11, 2016 8:32 PM
> >To: Tony Marston ; Stanislav Malyshev ; internals@lists.php.net
> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
composer/pickle
> >
> >
> >On 09/11/2016 10:47 AM, Tony Marston wrote:
>
On Sun, 11 Sep 2016, Sherif Ramadan wrote:
> On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston
> PEAR/PECL as a package manager has historically had little utility to the
> average user apart from installing those PECL extensions which aren't
> packaged by a particular user's distribution repository.
On Mon, 12 Sep 2016, Pierre Joye wrote:
> This RFC is about stop bundling it with the php releases and propose
> composer/pickle instead. Everything else has nothing to do with this
> RFC (aka web frontend, what happens or not on pear.php.net, its
> packages, etc.).
>
> To all: please re focus
Hi!
>> PEAR/PECL as a package manager has historically had little utility to the
>> average user apart from installing those PECL extensions which aren't
>> packaged by a particular user's distribution repository. Certainly hasn't
>> had any real viability in years. Trying to replace something tha
I think Derick has a good point here. I agree on the part that we should
stop bundling PEAR/PECL, but we might be rushing into pickle too fast.
2016-09-12 10:21 GMT+02:00 Derick Rethans :
> On Mon, 12 Sep 2016, Pierre Joye wrote:
>
> > This RFC is about stop bundling it with the php releases and
Hi!
> It's curious to see though that the off-topic comments get replies, but
> few real concerns do from the RFC author - such as not removing
> something before we have a confirmed alternative. I'd like to trial
> pickle first for a few releases and only then see whether to remove the
> PEAR
2016-09-12 10:21 GMT+02:00 Derick Rethans :
> On Mon, 12 Sep 2016, Pierre Joye wrote:
>
> > This RFC is about stop bundling it with the php releases and propose
> > composer/pickle instead. Everything else has nothing to do with this
> > RFC (aka web frontend, what happens or not on pear.php.net,
Hi,
> I know some code breaks, but it's not many. It's not fatal BC also.
>
> IMHO, uniqid() should try to generate uniqid() possible. uniqid() does produce
> non unique ID because it is system time based. This change mitigates impact of
> misuse also which is common in both open and close codes.
On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston
wrote:
> Sent: Sunday, September 11, 2016 11:44 AM
> >To: Tony Marston
> >Cc: Stanislav Malyshev ; internals@lists.php.net
> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
> composer/pickle
> >
> >On Sun, Sep 11, 2016 at 4:47 AM, Ton
On Mon, Sep 12, 2016 at 10:24 AM, Stanislav Malyshev
wrote:
> Hi!
>
> >> PEAR/PECL as a package manager has historically had little utility to
> the
> >> average user apart from installing those PECL extensions which aren't
> >> packaged by a particular user's distribution repository. Certainly
>
On Sep 12, 2016 3:24 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> >> PEAR/PECL as a package manager has historically had little utility to
the
> >> average user apart from installing those PECL extensions which aren't
> >> packaged by a particular user's distribution repository. Certainly
hasn't
>
On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote:
> On Mon, 12 Sep 2016, Pierre Joye wrote:
>
> > This RFC is about stop bundling it with the php releases and propose
> > composer/pickle instead. Everything else has nothing to do with this
> > RFC (aka web frontend, what happens or not on p
On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs wrote:
> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote:
>
> > On Mon, 12 Sep 2016, Pierre Joye wrote:
> >
> > > This RFC is about stop bundling it with the php releases and propose
> > > composer/pickle instead. Everything else has nothing
On Sep 12, 2016 6:51 PM, "Nikita Popov" wrote:
>
> On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs wrote:
>>
>> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote:
>>
>> > On Mon, 12 Sep 2016, Pierre Joye wrote:
>> >
>> > > This RFC is about stop bundling it with the php releases and propose
Hi Kazuo,
On Mon, Sep 12, 2016 at 7:48 PM, Kazuo Oishi wrote:
>> I know some code breaks, but it's not many. It's not fatal BC also.
>>
>> IMHO, uniqid() should try to generate uniqid() possible. uniqid() does
>> produce
>> non unique ID because it is system time based. This change mitigates imp
On Mon, Sep 12, 2016 at 9:08 PM, Yasuo Ohgaki wrote:
> It cannot not produce unique ID as name "uniqid()" implies by default.
It cannot not produce unique ID by default as name "uniqid()" implies.
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To un
Hi,
On Sep 12, 2016 5:48 PM, "Kazuo Oishi" wrote:
>
> Hi,
>
> > I know some code breaks, but it's not many. It's not fatal BC also.
> >
> > IMHO, uniqid() should try to generate uniqid() possible. uniqid() does
produce
> > non unique ID because it is system time based. This change mitigates
impac
On Mon, Sep 12, 2016 at 1:51 PM, Nikita Popov wrote:
> On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs wrote:
>
>> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote:
>>
>> > On Mon, 12 Sep 2016, Pierre Joye wrote:
>> >
>> > > This RFC is about stop bundling it with the php releases and prop
Hi Yasuo,
uniqid() has never been, and is not claimed to be, guaranteed unique to
any particular standard.
On 12/09/2016 13:08, Yasuo Ohgaki wrote:
Since we have to change "more entropy" to TRUE by default
Is your intention that the version without "more entropy" be deprecated,
and at som
Hi,
>> IMO, improving it (generate better semi-unique ID) is not important
>> enoungh to introduce unnecessary BC break. (Why returning string length
>> is changed?)
>
> It cannot not produce unique ID by default as name "uniqid()" implies.
> Reason is described in the RFC. Please read RFC becaus
On Mon, Sep 12, 2016 at 4:46 PM, Kazuo Oishi wrote:
> Hi,
>
> >> IMO, improving it (generate better semi-unique ID) is not important
> >> enoungh to introduce unnecessary BC break. (Why returning string length
> >> is changed?)
> >
> > It cannot not produce unique ID by default as name "uniqid()
On 9/11/2016 10:04 PM, Larry Garfield wrote:
> On 09/10/2016 05:55 AM, Fleshgrinder wrote:
>> @Larry what do you think about the CoW proposal?
>
> I'm afraid I got lost in the thread somewhere with the back and forth
> about implementation details. Can you repost the current proposal, or
> has the
Results for project PHP master, build date 2016-09-12 06:25:06+03:00
commit: ca5cfac
previous commit:fd5f0e4
revision date: 2016-09-12 00:08:16+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
>
> It is NOT insulting to say that people who still insist on using command
> line tools are living in the past for the simple reason that the command
> line interface was replaced with the GUI when the Windows OS was released
> in the 1990s. That is 25 years ago. Is that in the past or what? With
On 11.09.2016 at 12:35, Lester Caine wrote:
> On 11/09/16 11:05, Christoph M. Becker wrote:
> I have already debugged the problems and will tidy up the notes later
> when I cross check things. This is the sort of support I've always
> provided to the PHP project. The pages relating to the compile
On 12/09/16 20:31, Christoph M. Becker wrote:
> On 11.09.2016 at 12:35, Lester Caine wrote:
>
>> On 11/09/16 11:05, Christoph M. Becker wrote:
>
>> I have already debugged the problems and will tidy up the notes later
>> when I cross check things. This is the sort of support I've always
>> provid
On 09/12/2016 11:40 AM, Fleshgrinder wrote:
On 9/11/2016 10:04 PM, Larry Garfield wrote:
On 09/10/2016 05:55 AM, Fleshgrinder wrote:
@Larry what do you think about the CoW proposal?
I'm afraid I got lost in the thread somewhere with the back and forth
about implementation details. Can you repo
> -Original Message-
> From: Adam Baratz [mailto:adambar...@php.net]
> Sent: Sunday, September 11, 2016 9:37 PM
> To: Ferenc Kovacs
> Cc: PHP Group ; PHP Internals
> Subject: Re: [PHP-DEV] Re: VCS Account Request: adambaratz
>
> >
> > I've granted you with ext/pdo_dblib karma, it takes
I was following https://wiki.php.net/vcs/gitworkflow to make my first
commit to ext/pdo_dblib. I made a little mistake. I committed first to
PHP-7.0. I forgot about the PHP-7.1 branch and merged from PHP-7.0 to
master. I went back and merged from PHP-7.0 to PHP-7.1. All merges applied
cleanly, but
Hi!
On 9/12/16 2:53 PM, Adam Baratz wrote:
> I was following https://wiki.php.net/vcs/gitworkflow to make my first
> commit to ext/pdo_dblib. I made a little mistake. I committed first to
> PHP-7.0. I forgot about the PHP-7.1 branch and merged from PHP-7.0 to
> master. I went back and merged from
Adam,
> -Original Message-
> From: Adam Baratz [mailto:adambar...@php.net]
> Sent: Monday, September 12, 2016 11:54 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] merged branches in incorrect order
>
> I was following https://wiki.php.net/vcs/gitworkflow to make my first commit
> t
Hi Larry,
> On 13 Sep 2016, at 03:11, Larry Garfield wrote:
>
> On 09/12/2016 11:40 AM, Fleshgrinder wrote:
>> On 9/11/2016 10:04 PM, Larry Garfield wrote:
>>> On 09/10/2016 05:55 AM, Fleshgrinder wrote:
@Larry what do you think about the CoW proposal?
>>> I'm afraid I got lost in the threa
> To keep it clean, you can
>
> git checkout master
> git reset --hard origin/master
>
> and same for every branch containing a wrong merge. This will reset every
branch to the state of remote, after that you can repeat the merge clean
way.
Yes, but in this case, I'd already pushed.
On 09/12/2016 06:47 PM, Stephen Reay wrote:
Ah, I did see that one, but there was a lot of discussion after it so I thought
the idea evolved. Response below based on skimming the responses after that as
well...
It sounds like there's more that needs to go on, though. It sounds like that
thr
On Tue, Sep 13, 2016 at 3:06 AM, Lester Caine wrote:
> On 12/09/16 20:31, Christoph M. Becker wrote:
>> On 11.09.2016 at 12:35, Lester Caine wrote:
>>
>>> On 11/09/16 11:05, Christoph M. Becker wrote:
>>
>>> I have already debugged the problems and will tidy up the notes later
>>> when I cross che
Hi Rowan,
On Mon, Sep 12, 2016 at 10:47 PM, Rowan Collins wrote:
>
> uniqid() has never been, and is not claimed to be, guaranteed unique to any
> particular standard.
Right. We need to improve documentation. It only has crypt related
usage warning now.
> On 12/09/2016 13:08, Yasuo Ohgaki wrote
Hi Kazuo,
On Mon, Sep 12, 2016 at 11:46 PM, Kazuo Oishi wrote:
>>> IMO, improving it (generate better semi-unique ID) is not important
>>> enoungh to introduce unnecessary BC break. (Why returning string length
>>> is changed?)
>>
>> It cannot not produce unique ID by default as name "uniqid()"
Hi Marco,
On Mon, Sep 12, 2016 at 11:48 PM, Marco Pivetta wrote:
>
> Full ACK on what Kazuo said.
>
> I use `uniqid()` daily in my test suites, even new ones (not much else), and
> introducing the `.` everywhere will just cause issues.
> Changing string length may also break everything.
It seems
On Tue, Sep 13, 2016 at 10:14 AM, Yasuo Ohgaki wrote:
>> I use `uniqid()` daily in my test suites, even new ones (not much else), and
>> introducing the `.` everywhere will just cause issues.
>> Changing string length may also break everything.
>
> It seems you have code that will be broken.
> Cou
Hi all,
I've updated session security manual page a lot.
http://php.net/manual/en/session.security.php
Some of us do not realize importance of non adoptive session
management and timestamp management. e.g.
https://wiki.php.net/rfc/precise_session_management
https://wiki.php.net/rfc/session-use-st
Hi,
IMO, improving it (generate better semi-unique ID) is not important
enoungh to introduce unnecessary BC break. (Why returning string length
is changed?)
>>>
>>> It cannot not produce unique ID by default as name "uniqid()" implies.
>>> Reason is described in the RFC. Please rea
On Tue, Sep 13, 2016 at 11:23 AM, Kazuo Oishi wrote:
> IMO, improving it (generate better semi-unique ID) is not important
> enoungh to introduce unnecessary BC break. (Why returning string length
> is changed?)
It cannot not produce unique ID by default as name "uniqid()" i
Hi Kazuo,
On Tue, Sep 13, 2016 at 11:48 AM, Yasuo Ohgaki wrote:
>> Current "more_entropy" part (10 bytes) pattern is "n." and its
>> variation is 10^9 (1 billion) as written in your RFC. (about 30bits?)
>>
>> I think it is enough to avoid collision in the same usec, for
>> non-security p
Hi,
> Actually not with current implementation. If time is rewined, the same ID
> could be generated by chance. Because, both ID part and entropy part
> is generated based on the current system time. Collision would be rare,
> but it's not rare as it should be at all.
>
> I think minimum would be
Hi Kazuo,
On Tue, Sep 13, 2016 at 1:20 PM, Kazuo Oishi wrote:
> The uniqid() manual explicitly say,
>
> - default value of more_entropy is false
>
> - the returned string will be 13 characters long. If more_entropy is
>TRUE, it will be 23 characters.
>
> - if more_entropy is set to TRUE, u
Hi,
>> The uniqid() manual explicitly say,
>>
>> - default value of more_entropy is false
>>
>> - the returned string will be 13 characters long. If more_entropy is
>>TRUE, it will be 23 characters.
>>
>> - if more_entropy is set to TRUE, uniqid() will add additional entropy
>>(using th
Thanks a lot for your feedback.
I like the clone idea too and I also see no harm in allowing them in any
context rather than only in immutable classes. I am really against the
transformer keyword, don't ask me why, I just don't like it at all. :P
I mentioned before that PHP should allow for opera
50 matches
Mail list logo
