Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71934
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Pierre Joye <pierre.php@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Christopher Jones
 <christopher.jones@oracle.com>, Anatol Belski <anatol.php@belski.net>, PHP
 Developers Mailing List <internals@lists.php.net>
In-Reply-To: <CAEZPtU6BF5zixmq4egOESBacqNCSSR6NLKN4bxPpePC8zskJRA@mail.gmail.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	 <52EAF0A3.2000001@oracle.com>
	 <1d5850561e0ef9e7739c7e7b7b0448d0.squirrel@webmail.klapt.com>
	 <52EC0B34.8080109@oracle.com>
	 <d41c0659b516306ea4eb534723f3d771@mail.gmail.com>
	 <CAEZPtU6k9cBBcVv7B5MMzmsYJcUROAy4Bsqqu184-dyCCghU7A@mail.gmail.com>
	 <1391281911.2941.316.camel@guybrush>
	 <CAEZPtU6BF5zixmq4egOESBacqNCSSR6NLKN4bxPpePC8zskJRA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 01 Feb 2014 20:43:45 +0100
Message-ID: <1391283825.2941.327.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
 length and integer
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Sat, 2014-02-01 at 20:30 +0100, Pierre Joye wrote:
> On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schlüter
> <johannes@schlueters.de> wrote:
> > On Sat, 2014-02-01 at 19:35 +0100, Pierre Joye wrote:
> >> It is not, there is no change from user level but on windows and a 1-2
> >> other platforms with long being 32 bit in 64bit.
> >
> > The current rule isn't precise, different interpretations are possible.
> > I lean to the side that a big change to the APIs is comparable to a
> > userland language change. I can see that this is read differently.
> 
> 
> This section of the RFC aims to protect from not well designed
> addition to the language, things affecting the long term maintenance
> and its core design.

... like core API design ... ;-)

> To make the internals implementation and APIs more 64bit aware, safer,
> cleaner and easier to deal with 64bit (compilation time check f.e.) is
> not something covered by this section.

I understand your interpretation of the text, and going by the wording
this might be correct, I still consider internal core APIs comparable.

> >> Also I find amazingly disturbing the amount of efforts you are putting
> >> to shut down this RFC, without a single comment in the last months or
> >> weeks, not even now to explain your vote.
> >>
> >> I do not mind a no, but what is happening here is disgusting, to say it nicely.
> >
> > Many contributors mentioned their concern about pushing in a patch
> > changing more than 20,000 lines of code now.
> 
> Stability of this patch has been proven. Work has began for months.
> And if you look at the actual changes, they are much less problematic
> than a couple of small patches having disturbing releases for ages, or
> last minute addition of totally unstable extension, delaying release
> and early adoption for months.

Even though it might be "proven" there are still issues, i.e.

21:53 < LawnGnome> cjones: 
/home/aharvey/trees/php-src/int64/ext/mysqli/mysqli_api.c:683:12: error: 
                   conflicting types for âmysqli_commit_or_rollback_libmysqlâ

That one is most likely trivial (haven't done a libmysql build on that
branch) to fix

22:05 <@johannes_> LawnGnome: should be a quite simple fix ... change 
                   mysqli_tx_cor_options_to_string and 
                   mysqli_commit_or_rollback_libmysql's signature touse the new 
                   type
22:06 < LawnGnome> johannes_: I'm sure you're right. I just disabled mysqli for 
                   now âÂ I just want something I can phpize from so I can start
                   seeing how good/bad/otherwise porting an extension to this 
                   is going to be for myself.

but there likely are other small oversights.

> >I haven't seen much critic
> > on the implementation itself, simply the request for more time to
> > a) review it to make sure there are no accidental errors from conversion
> > and
> 
> 99% of the implementation and options about it have been around for
> literally months. Sorry, this argument is totally invalid.

I comment on that further down in my previous message.

> > b) time to learn "the new way" before putting in a release, many have to
> > relearn thins hardwired in the brain for more than 10 years, such
> > adoption takes some time.
> 
> I don't think anyone with little C experience needs more than 15mins
> to understand the changes, given the extensively verbose and migration
> guide.

The issue is not reading it, but current type choices I can quote when
woken at night and made drunk. Adoption takes time.

> > Yes, we might have reviewed the branch sooner and learned the details
> > sooner but we are lazy and holding back in investing time in
> > "experimental" things.
> 
> There is nothing experimental in this patch but a long awaited due
> cleanup and safe changes. We have been talking about that for ages.
> Our team finally took the beast by its horn and put a working, clean
> and safe patch. They tested it, very early, constantly, provided
> regular updates and requested feedback since months. I, personally, do
> not buy the laziness and lack of time argument.

I've seen mostly messages appreciating the work.

> > I think a good way to proceed is to put it in master now and leave it
> > from 5.6. This forces everybody to look into it (and we will have lots
> > of opportunity to learn due to merging pain [which we have when putting
> > in 5.6, too]) and gives everybody enough time to adopt their brain and
> > prepare pecl (and internal) exts.
> 
> That won't happen without another RFC and votes. We also drop all the
> options as we are most likely targeting 6 anyway. I won't be surprised
> to see the same arguments coming again btw :)

Most messages I have read and most chatter I have seen rejects not the
patch itself but the strong pushing it in with this timing. I think
acceptance for master would be there. (unless people have too much time
and find actual technical issues, of which I'm not aware)

johannes