On 8/22/14, 10:46 PM, Pierre Joye wrote:
In other words, it would be nice to see more developers actually
porting extensions to realize the amount of changes are introduced by
NG and by the int64. The sooner is in order of magnitude must larger.
It is not a bad comment, only a fact. Given
On Sat, Aug 23, 2014 at 8:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 10:46 PM, Pierre Joye wrote:
In other words, it would be nice to see more developers actually
porting extensions to realize the amount of changes are introduced by
NG and by the int64. The sooner is in order
On 8/22/14, 11:09 PM, Pierre Joye wrote:
On Sat, Aug 23, 2014 at 8:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 10:46 PM, Pierre Joye wrote:
In other words, it would be nice to see more developers actually
porting extensions to realize the amount of changes are introduced by
NG
On Sat, Aug 23, 2014 at 8:21 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 11:09 PM, Pierre Joye wrote:
On Sat, Aug 23, 2014 at 8:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 10:46 PM, Pierre Joye wrote:
In other words, it would be nice to see more developers actually
I think it's ok to keep zend_off_t and zend_size_t as is.
Thanks. Dmitry,
On Fri, Aug 22, 2014 at 4:09 PM, Anatol Belski anatol@belski.net
wrote:
Hi Nikita,
On Fri, August 22, 2014 13:16, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections
100% agree with RFC.
It would be great if technical improvements wouldn't be messed with this
renaming :(
Thanks. Dmitry,
On Fri, Aug 22, 2014 at 3:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming
On Aug 23, 2014 11:55 AM, Dmitry Stogov dmi...@zend.com wrote:
100% agree with RFC.
It would be great if technical improvements wouldn't be messed with this
renaming :(
You realize that 80%+ of the zval macros has to be changed as well right?
And not only the name but the argument and their
On 23 Aug 2014, at 10:43, Dmitry Stogov dmi...@zend.com wrote:
I think it's ok to keep zend_off_t and zend_size_t as is.
Could someone enlighten me as to why we need zend_size_t? Isn’t that just a
typedef for size_t? It’s not like it’ll vary on different platforms, doing so
would defeat the
On Aug 23, 2014 4:34 PM, Andrea Faulds a...@ajf.me wrote:
On 23 Aug 2014, at 10:43, Dmitry Stogov dmi...@zend.com wrote:
I think it's ok to keep zend_off_t and zend_size_t as is.
Could someone enlighten me as to why we need zend_size_t? Isn’t that just
a typedef for size_t? It’s not like
On 23 Aug 2014, at 16:00, Pierre Joye pierre@gmail.com wrote:
uint32_t for zend_uint (solving the
zend_uint vs zend_into_t).
uint32_t isn’t universally available. MSVC 2010 does not have it, for example.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
On Aug 23, 2014 5:02 PM, Andrea Faulds a...@ajf.me wrote:
On 23 Aug 2014, at 16:00, Pierre Joye pierre@gmail.com wrote:
uint32_t for zend_uint (solving the
zend_uint vs zend_into_t).
uint32_t isn’t universally available. MSVC 2010 does not have it, for
example.
It would be nice to
On 8/22/14, 11:25 PM, Pierre Joye wrote:
There is. Long is not used anymore. So we can argue about that but
there is a change and it should be reflected imo.
You still totally ignore any of my other points, which are even more
important in regard to maintaining one code tree for 5.x and 7.x,
On Sat, Aug 23, 2014 at 6:40 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 11:25 PM, Pierre Joye wrote:
There is. Long is not used anymore. So we can argue about that but
there is a change and it should be reflected imo.
You still totally ignore any of my other points, which are
On Aug 23, 2014 12:10 PM, Pierre Joye pierre@gmail.com wrote:
On Sat, Aug 23, 2014 at 6:40 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 8/22/14, 11:25 PM, Pierre Joye wrote:
There is. Long is not used anymore. So we can argue about that but
there is a change and it should be
On 23 Aug 2014, at 20:19, Kris Craig kris.cr...@gmail.com wrote:
I have a quick question for the people debating this issue: Aside from the
dispute over whether or not it's necessary / unimportant, are there any
pressing reasons *not* to implement the changes that Pierre is advocating?
I.e.
On Sat, Aug 23, 2014 at 9:29 PM, Andrea Faulds a...@ajf.me wrote:
On 23 Aug 2014, at 20:19, Kris Craig kris.cr...@gmail.com wrote:
I have a quick question for the people debating this issue: Aside from the
dispute over whether or not it's necessary / unimportant, are there any
pressing
On 23 Aug 2014, at 20:38, Pierre Joye pierre@gmail.com wrote:
Please try to port one. That will solve this never ending ping pong
game. Extensions are broken per se with ng, almost every zval macros
usage must change (some disappeared, like the _PP ones), all hash APIs
call must be
On Sat, Aug 23, 2014 at 9:41 PM, Andrea Faulds a...@ajf.me wrote:
On 23 Aug 2014, at 20:38, Pierre Joye pierre@gmail.com wrote:
Please try to port one. That will solve this never ending ping pong
game. Extensions are broken per se with ng, almost every zval macros
usage must change (some
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and instead use type
On Fri, 2014-08-22 at 13:16 +0200, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to
Am 22.8.2014 um 13:16 schrieb Nikita Popov nikita@gmail.com:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which
On Fri, 22 Aug 2014, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge,
a short proposal has been created, which aims to revert all
Hi Nikita,
On Fri, August 22, 2014 13:16, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which
On Fri, Aug 22, 2014 at 1:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been
On Fri, Aug 22, 2014 at 1:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been
On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Yes, please. We're all in favor of the 64 bit implementation, but definitely
not on
the naming. I think it was a big mistake to not separate the naming and
implementation votes initially.
I also would support a shorter
Pierre Joye in php.internals (Fri, 22 Aug 2014 14:17:04 +0200):
And I'd to remember that we suffer from double standards while you
guys do whatever you want with ng, and certainly with ast as well.
Just a side note: talking in you guys and we is not constructive. I
had the idea you had come a lot
On 8/22/14, 5:11 AM, Pierre Joye wrote:
On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Yes, please. We're all in favor of the 64 bit implementation, but definitely
not on
the naming. I think it was a big mistake to not separate the naming and
implementation votes
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and instead use type names that are consistent with the
existing
Andrea Faulds in php.internals (Fri, 22 Aug 2014 16:32:51 +0100):
Im very much in favour of this RFC. It is not necessary to change
the type names after all; if people turn on compiler warnings, theyll
find out whats broken anyway.
'people'? Which people?
Will a normal user ever notice
2014.08.22. 17:56 ezt írta (Jan Ehrhardt php...@ehrhardt.nl):
Andrea Faulds in php.internals (Fri, 22 Aug 2014 16:32:51 +0100):
I’m very much in favour of this RFC. It is not necessary to change
the type names after all; if people turn on compiler warnings, they’ll
find out what’s broken
Ferenc Kovacs in php.internals (Fri, 22 Aug 2014 18:59:01 +0200):
People means ext devs here.
OK.
The concern raised here that if we delay the namechange then early
adopters(ext developers adding support for php7) have to update their code
twice.
Provided the name change (back!) is agreed upon.
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and
On 8/22/14, 11:38 AM, Pierre Joye wrote:
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert
On 23 Aug 2014, at 03:05, Rasmus Lerdorf ras...@lerdorf.com wrote:
The end result here is likely that in order to write a portable
extension, extension authors will simply do:
#ifndef IS_LONG
# define IS_LONG IS_INT
# define Z_STRLEN Z_STRSIZE
# define RETURN_LONG RETURN_INT
# define
hi Rasmus,
On Sat, Aug 23, 2014 at 4:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 11:38 AM, Pierre Joye wrote:
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to
36 matches
Mail list logo
