Hi!
After a quick check
6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1
f86b219 and 3728449 are in 5.6.1RC1 only
So, for 5.4 should we revert 6569db8 and 32be79d then? What about
upmerging to 5.5? What about f86b2193, should this be reverted too? I'm
feeling I don't understand what is
Hi!
I will review and report back on the 5.6.1 later today. I've checked with
the horde folks and my recent uncommitted patch resolves any bugs (both old
and new). I plan to commit this for 5.4 and 5.5 today and then subsequently
What is this new patch? Please note 5.4 is now supposed to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 25/09/2014 09:00, Stas Malyshev a écrit :
Hi!
Hi,
After a quick check
Too quick, I miss 84a4041 ;)
6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 f86b219
and 3728449 are in 5.6.1RC1 only
So, for 5.4 should we revert 6569db8 and
Hi!
As you said, 5.4 is now supposed to be security-only so I rather
think we should revert to 5.4.32 code and have the upcoming fix only
in 5.5+ (so in 5.5.18RC and 5.6.2RC)
OK, I'll revert it then to 5.4.32 state tomorrow. But the problem is
up-merging it - are there any fixes already
On 25/09/14 06:19, Patrick Schaaf wrote:
Am 24.09.2014 22:01 schrieb Andrea Faulds a...@ajf.me:
Now, if we were to add actual object key support, that I might like. But
if we’re going to keep with just integers and strings, I’d much prefer to
just support __toString here. I think users are
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
On 25 September 2014 08:40, Lester Caine les...@lsces.co.uk wrote:
Why would we need to build a hash of this object? It would provide
nothing of use since we have a clean object key. Some people seem to
think a hash will provide an indication that an object has changed, but
in reality that is
Hi! I'm typing on my phone at the airport so apologies for the brevity and
lack of quoting from previous messages. I will summarize everything in
detail with commit references to clear up any confusion in the next couple
of days.
I believe that by applying the patch below to the 5.4 and 5.5
On 25 September 2014 08:42, Dmitry Stogov dmi...@zend.com wrote:
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
Since in the should people be allowed to vote thread, I said I think
people should explain their votes, here is my explanation
On Thu, Sep 25, 2014 at 7:28 AM, Daniel Lowrey rdlow...@php.net wrote:
FYI: I've tagged 5.6.1 and I had to revert the following commits for
this:
372844918a318ad712e16f9ec636682424a65403
f86b2193a483f56b0bd056570a0cdb57ebe66e2f
30a73658c63a91c413305a4c4d49882fda4dab3e
On 25/09/14 08:44, Leigh wrote:
On 25 September 2014 08:40, Lester Caine les...@lsces.co.uk wrote:
Why would we need to build a hash of this object? It would provide
nothing of use since we have a clean object key. Some people seem to
think a hash will provide an indication that an object
Rowan Collins wrote (on 24/09/2014):
On 24/09/2014 22:33, Andrea Faulds wrote:
On 24 Sep 2014, at 22:17, Rowan Collins rowan.coll...@gmail.com wrote:
Perhaps rather than a magic function or constant, though, the switch
statement could be extended with an as argument, which would store
the
On 25 September 2014 09:21, Lester Caine les...@lsces.co.uk wrote:
'This function returns a unique identifier for the object.'
There is a mistaken view in some usage that that will be DIFFERENT for
different versions of the same object.
Not sure who has that view. It's quite clearly
On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds a...@ajf.me wrote:
On 24 Sep 2014, at 20:39, Stas Malyshev smalys...@sugarcrm.com wrote:
I also wonder why we still need them. Doing what has been done with gmp
for all resources would be a good move for 7.
In general, I think we do not - IIRC
Mit freundlichen Grüßen aus Paderborn
Christian Stoller
Softwareentwicklung
LEONEX Internet GmbH
Technologiepark 20
33100 Paderborn
Tel: 05251-14807-27
Fax: 05251-14807-30
HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter
Hi,
Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
https://github.com/krakjoe/php-src/compare/addressof
I think it makes more sense than a new method on all objects. You could use
it for any kind of value: scalar, resource, object. Building an array of
sockets, for
Christian Stoller wrote (on 25/09/2014):
Am I missing something equally obvious there? Or just, it doesn't
interest people much as an idea?
Why should one add a new operator in that context if it is already
possible with assigments as expressions?
This makes the language more complex without
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 12:31 PM
Sorry, I was talking about this bit:
Currently, switch always uses a loose comparison (==), so cannot
distinguish between case 3 and case 3.0. Occasionally, it would be
nice to switch on a
Hi,
On Thu, 2014-09-25 at 12:22 +0200, Florian Margaine wrote:
Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
https://github.com/krakjoe/php-src/compare/addressof
I think it makes more sense than a new method on all objects. You could use
it for any kind of value:
Christian Stoller wrote (on 25/09/2014):
From: Rowan Collins [mailto:rowan.coll...@gmail.com], Sent: Thursday, September
25, 2014 12:31 PM
Sorry, I was talking about this bit:
Currently, switch always uses a loose comparison (==), so cannot
distinguish between case 3 and case 3.0.
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline-extended_value ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot. :)
enabling
Andrea Faulds wrote (on 25/09/2014):
No bogus value ever gets to a function - it always gets INT_MAX on
overflow. If INT_MAX is harmful for this function, this change
does not
help as you could still pass INT_MAX and this change would not do
anything.
No it won't. Normally it truncates
Hi everyone,
On 25 Sep 2014, at 17:27, Patrick ALLAERT patrickalla...@php.net wrote:
[...]
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.
Voted in favour of disabling as well but could easily live with the other
option as everything is better
2014-09-25 9:42 GMT+02:00 Dmitry Stogov dmi...@zend.com:
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
Hi,
I'm in favor of disabling for consistency as well, however, I wish a
warning would be emitted.
Not only it would tell me that I
On 25.09.14 09:42, Dmitry Stogov wrote:
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Voted +1 for disabling.
I think string handling needs more thorough designing and planning for
edge case and such; i.e. the string handling alternative seems to rushed
to me
On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov dmi...@zend.com wrote:
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline-extended_value ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's
On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov nikita@gmail.com wrote:
On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov dmi...@zend.com wrote:
disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for
FETCH_DIM_TMP_VAR is used especiualy for list().
It expects array, don't check for objects and strings.
It doesn't remove the operand and allow it's reuse in next opcode.
FETCH_DIM_R is used for list() only in some cases (when operand IS_VAR).
To work in list() context it has to keep operand not
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 12:45 AM, Nikita Popov nikita@gmail.com wrote:
On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov nikita@gmail.com
wrote:
On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?
--
Stanislav Malyshev, Software Architect
SugarCRM:
On 25 September 2014 22:50, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it
On Thu, Sep 25, 2014 at 11:50 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.
It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.
I would prefer not to extend list() to support strings, but in case
Hey:
On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov dmi...@zend.com wrote:
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.
It's not complicated to change it in any way.
The question which way is better, and it's the reason
On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov dmi...@zend.com wrote:
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.
It's not complicated to
35 matches
Mail list logo
