On Fri, Aug 22, 2014 at 8:45 AM, Dmitry Stogov wrote:
> zend_long/zend_ulong without renaming everything else would be a perfect
> solution from my point of view.
Again, no. long is the worst type ever, be as type or in names (ppl
then use this type to match the macro names).
If there is a need
zend_long/zend_ulong without renaming everything else would be a perfect
solution from my point of view.
Thanks. Dmitry.
On Fri, Aug 22, 2014 at 12:49 AM, Nikita Popov wrote:
> On Thu, Aug 21, 2014 at 7:23 PM, Dmitry Stogov wrote:
>
>> Hi,
>>
>> Thanks to Anatol and Pierre the 64-bit patch is
Hello!
The PHP development team announces the immediate availability of PHP
5.4.32.
16 bugs were fixed in this release, including the following
security-related issues:
CVE-2014-2497, CVE-2014-3538, CVE-2014-3587, CVE-2014-3597,
CVE-2014-4670, CVE-2014-4698, CVE-2014-5120.
All PHP 5.4 users are
Hey:
On Thu, Aug 21, 2014 at 11:30 PM, Derick Rethans wrote:
> On Tue, 19 Aug 2014, Kris Craig wrote:
>
>> On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds wrote:
>>
>> > I have made an RFC which would make some small changes to how integers
>> > are handled, targeted at PHP 7:
>> >
>> > htt
On Aug 21, 2014 10:49 PM, "Nikita Popov" wrote:
>
> I am against merging this with the long->int rename everywhere. This
seems like change for the sake of change.
It is accepted and ready to be merged.
> I am also concerned that we now have zend_uint_t (a 64-bit integer type)
and zend_uint (a 3
On 17 Aug 2014, at 20:58, Marc Bennewitz wrote:
>
> I've created a draft RFC and patch to change the behavior of non-strict
> string to string comparison to be binary safe (as the strict comparison
> operator does):
>
> https://wiki.php.net/rfc/binary_string_comparison
>
> On comparing
On Thu, 21 Aug 2014, Marc Bennewitz wrote:
> On 21.08.2014 17:30, Derick Rethans wrote:
> > On Tue, 19 Aug 2014, Kris Craig wrote:
> >
> > > On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds wrote:
> > >
> > > > I have made an RFC which would make some small changes to how integers
> > > > are ha
On 21 Aug 2014, at 21:49, Nikita Popov wrote:
> I am also concerned that we now have zend_uint_t (a 64-bit integer type)
> and zend_uint (a 32-bit integer type). Notice the difference? Yes, it's the
> missing _t.
>
> I would appreciate it if we could consider the following naming convention:
>
On Thu, Aug 21, 2014 at 7:23 PM, Dmitry Stogov wrote:
> Hi,
>
> Thanks to Anatol and Pierre the 64-bit patch is ready
> https://github.com/weltling/php-src
>
> I made quick code review and don't see any technical problems now.
>
> The performance and memory consumption difference is negligible. s
On Thu, Aug 21, 2014 at 8:30 AM, Derick Rethans wrote:
> On Tue, 19 Aug 2014, Kris Craig wrote:
>
> > On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds wrote:
> >
> > > I have made an RFC which would make some small changes to how integers
> > > are handled, targeted at PHP 7:
> > >
> > > https://
On 21.08.2014 17:30, Derick Rethans wrote:
On Tue, 19 Aug 2014, Kris Craig wrote:
On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds wrote:
I have made an RFC which would make some small changes to how integers
are handled, targeted at PHP 7:
https://wiki.php.net/rfc/integer_semantics
Thoug
What if we were to *quantify* backwards compatibility in a way, as opposed
to just discussing the hypothetical BC breaking potential of a change?
I've never thought of this before, but this discussion had me thinking...
When I write a library that has a large user base, I try to write as many
unit
I suppose calling it statically a user would probably want to recycle the
same function/closure, so binding/calling it real time would have little
impact if done properly.
On Wed, Aug 20, 2014 at 2:30 PM, Levi Morrison wrote:
> On Wed, Aug 20, 2014 at 11:51 AM, Nathan wrote:
> > The only thing
Matt Ficken
wrote:
> I'm sharing the run-test output for master/phpng on Windows here:
>
> http://131.107.220.66/PFTT-Results/Share/20140821/phpng_phpt_windows.txt
>
>
> Also, I'm sharing the Joomla phpunit output here:
>
> http://131.107.220.66/PFTT-Results
I'm sharing the run-test output for master/phpng on Windows here:
http://131.107.220.66/PFTT-Results/Share/20140821/phpng_phpt_windows.txt
Also, I'm sharing the Joomla phpunit output here:
http://131.107.220.66/PFTT-Results/Share/20140821/phpunit_Joomla-Platform-12.3_Local-FileS.xml
In worst case, we will always able to make a new RFC and rename them back,
but I really don't like to delay this patch just because few people
(including me) are not agree with names. RFC was already delayed for
months, and actually, it was voted with section about new names.
Thanks. Dmitry.
On
Master (with PHPNG) builds on Windows (our snapshot build servers were
never interrupted BTW), though extensions including PDO, mysql and soap
are disabled.
Master on Windows now has 201 test failures(all sapi scenarios) while Linux
(for me at least) only has about 20 failures, see:
http://qa.ph
I completely agree.
Dmitry.
On Thu, Aug 21, 2014 at 10:21 PM, Pierre Joye wrote:
>
> On Aug 21, 2014 8:14 PM, "Dmitry Stogov" wrote:
> >
> > Pierre, wait a day, and if we won't have many developers, who against
> the new names - commit it as is.
> >
> > Thanks. Dmitry.
> We have waited months
On 21 Aug 2014, at 19:21, Pierre Joye wrote:
> Why should we follow different rules than other RFCs? Bigint is a work in
> progress, there is no vote, there is not even a discussion on this list about
> it. Asking us to hang on again for yet another rfc is really not something I
> can live wi
On Aug 21, 2014 8:14 PM, "Dmitry Stogov" wrote:
>
> Pierre, wait a day, and if we won't have many developers, who against the
new names - commit it as is.
>
> Thanks. Dmitry.
We have waited months due to phpng. We have waited months due to objection
after the rfc was accepted already (2nd attempt)
Hi!
>> And since you're targetting the next major release, BC isn't an issue.
>
> This sort of blanket statements that "Backwards Compatibility is not an
> issue" with a new major version is extremely unwarranted. *Extreme care*
> should be taken when deciding to break Backwards Compatibility. It
On 21 Aug 2014, at 19:14, Dmitry Stogov wrote:
> Pierre, wait a day, and if we won't have many developers, who against the new
> names - commit it as is.
Perhaps none will be against it now, however, how will they feel when they have
to change IS_INT in their extensions *again* to a new name
On 8/21/14, 11:09 AM, Levi Morrison wrote:
Every time we break BC — in either of the ways Derick said — we narrow
the subset of PHP 5 and PHP 7 that's available to people writing PHP
code that has to work on both. If we narrow it too far, it'll be too
unexpressive, or too hard to use, or just p
Pierre, wait a day, and if we won't have many developers, who against the
new names - commit it as is.
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 10:03 PM, Pierre Joye wrote:
>
> On Aug 21, 2014 7:58 PM, "Andrea Faulds" wrote:
> >
> >
> > On 21 Aug 2014, at 18:56, Pierre Joye wrote:
> >
> > > T
On 21 Aug 2014, at 19:08, Pierre Joye wrote:
> Then please do a rfc, but we are not going to rewamp the patch for the 6th
> time. It has been accepted and we have been more than cooperative.
Do we really need to delay this by three weeks?
Forgive me if I’m wrong, but wouldn’t changing the
> Every time we break BC — in either of the ways Derick said — we narrow
> the subset of PHP 5 and PHP 7 that's available to people writing PHP
> code that has to work on both. If we narrow it too far, it'll be too
> unexpressive, or too hard to use, or just plain won't do something
> that they'll
On Aug 21, 2014 8:05 PM, "Andrea Faulds" wrote:
>
>
> On 21 Aug 2014, at 19:03, Pierre Joye wrote:
>
> > Now to be honest I would merge it right away. I do not see why we need
to discuss that again. When I see how phpng got accepted without a word,
time to stop arguing about such things. Merge an
On 21 Aug 2014, at 18:56, Pierre Joye wrote:
> The original patch used the right naming based on the type used behind it.
So IS_LONGLONG, then?
> In any case, the patch represents what the rfc and the discussions around
> it say. I rather merge it asal and begin on the (long) list of todos for
On 21 Aug 2014, at 19:03, Pierre Joye wrote:
> Now to be honest I would merge it right away. I do not see why we need to
> discuss that again. When I see how phpng got accepted without a word, time to
> stop arguing about such things. Merge and move back to code. If one thinks
> that one thin
On Aug 21, 2014 7:58 PM, "Andrea Faulds" wrote:
>
>
> On 21 Aug 2014, at 18:56, Pierre Joye wrote:
>
> > The original patch used the right naming based on the type used behind
it.
>
> So IS_LONGLONG, then?
The original patch, the one from last year. We have made compromises to
fulfill other devs
On Aug 21, 2014 7:42 PM, "Andrea Faulds" wrote:
>
>
> On 21 Aug 2014, at 18:23, Dmitry Stogov wrote:
>
> > The only thing that I don't like is a massive renaming described here
> >
https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings
> >
> > IS_LONG -> IS_INT
> > Z_LVAL -> L_
On 8/21/14, 10:23 AM, Dmitry Stogov wrote:
Hi,
Thanks to Anatol and Pierre the 64-bit patch is ready
https://github.com/weltling/php-src
I made quick code review and don't see any technical problems now.
The performance and memory consumption difference is negligible. see
https://docs.google
On 21 Aug 2014, at 18:28, Adam Harvey wrote:
> Every time we break BC — in either of the ways Derick said — we narrow
> the subset of PHP 5 and PHP 7 that's available to people writing PHP
> code that has to work on both. If we narrow it too far, it'll be too
> unexpressive, or too hard to use,
On 21 Aug 2014, at 18:23, Dmitry Stogov wrote:
> The only thing that I don't like is a massive renaming described here
> https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings
>
> IS_LONG -> IS_INT
> Z_LVAL -> L_IVAL
> etc
>
> On one hand using INT may be more consistent, on
On 21 August 2014 08:30, Derick Rethans wrote:
> Can I please urge people to not take Backwards Compatibility issues so
> lightly. Please think really careful when you suggest to break Backwards
> Compatibility, it should only be considered if there is a real and
> important reason to do so. Chang
Hi,
Thanks to Anatol and Pierre the 64-bit patch is ready
https://github.com/weltling/php-src
I made quick code review and don't see any technical problems now.
The performance and memory consumption difference is negligible. see
https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq
On Tue, 19 Aug 2014, Kris Craig wrote:
> On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds wrote:
>
> > I have made an RFC which would make some small changes to how integers
> > are handled, targeted at PHP 7:
> >
> > https://wiki.php.net/rfc/integer_semantics
> >
> > Thoughts and questions are
On Tue, 19 Aug 2014, Andrea Faulds wrote:
> Good evening,
>
> I have made an RFC which would make some small changes to how integers are
> handled, targeted at PHP 7:
>
> https://wiki.php.net/rfc/integer_semantics
I think it is good to make sure it behaves the same on all systems.
However, I
Hi!
> Can you post the list of failed tests
Can be seen here:
https://travis-ci.org/php/php-src/jobs/33142160
the list isn't full because it times out now (also shows multiple **
ERROR: process timed out ** messages).
If you look there for "Segmentation fault" or "*** glibc detected ***"
you'll
Hi Stas,
Can you post the list of failed tests
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 11:49 AM, Stas Malyshev
wrote:
> Hi!
>
> >
> > Committed and it works, the build done at travis finished OK.
>
> Yes, I saw it, thanks. A number of tests on debug version have errors or
> segfaults or glibc
Hi!
>
> Committed and it works, the build done at travis finished OK.
Yes, I saw it, thanks. A number of tests on debug version have errors or
segfaults or glibc memory errors. Somebody probably should look into this.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
On Wed, Aug 20, 2014 at 3:41 PM, Levi Morrison wrote:
> On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis
> wrote:
> > On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans wrote:
> >
> >> Hi Nikita,
> >>
> >> I reviewed the AST RFC on my way to vote but there was something that
> >> wasn’t clear to me.
42 matches
Mail list logo
